Re: X32 psABI status

[Florian Weimer]

* H. Peter Anvin:

> On 02/12/2011 01:10 PM, Florian Weimer wrote:
>> Why is the ia32 compatiblity kernel interface used?
>
> Because there is no way in hell we're designing in a second
> compatibility ABI in the kernel (and it has to be a compatibility ABI,
> because of the pointer size difference.)

Actually, I'm wondering if you can do the translation in user space.
There already are 32-on-64 implementations in existence, without
kernel changes (recent Hotspot, LuaJIT, and probably some more).

GCC bootstrap mismatch on OS X 10.4

[Csaba Raduly]

Hi all,
I'm trying to build GCC (r170071) on powerpc-apple-darwin8.11.0 (a G4
Mac Mini with OS X 10.4.11). I built and installed gmp-5.0.1,
mpc-0.8.2 and mpfr-3.0.0, then ran

../gcc/configure --enable-languages=c,c++
make bootstrap

This failed with:

libtool: link: /Users/useruser/GCC/build/./gcc/xgcc
-B/Users/useruser/GCC/build/./gcc/
-B/usr/local/powerpc-apple-darwin8.11.0/bin/
-B/usr/local/powerpc-apple-darwin8.11.0/lib/ -isystem
/usr/local/powerpc-apple-darwin8.11.0/include -isystem
/usr/local/powerpc-apple-darwin8.11.0/sys-include  -m64 -dynamiclib
-Wl,-fl
libtool: link: dsymutil .libs/libgomp.1.dylib || :
warning: no debug map in executable (-arch ppc64)
libtool: link: (cd ".libs" && rm -f "libgomp.dylib" && ln -s
"libgomp.1.dylib" "libgomp.dylib")
libtool: link: ar rc .libs/libgomp.a  alloc.o barrier.o critical.o
env.o error.o iter.o iter_ull.o loop.o loop_ull.o ordered.o parallel.o
sections.o single.o task.o team.o work.o lock.o mutex.o proc.o sem.o
bar.o ptrlock.o time.o fortran.o affinity.o
libtool: link: ranlib -c .libs/libgomp.a
libtool: link: ( cd ".libs" && rm -f "libgomp.la" && ln -s
"../libgomp.la" "libgomp.la" )
true  DO=all multi-do # make
make "DESTDIR=" "RPATH_ENVVAR=DYLD_LIBRARY_PATH"
"TARGET_SUBDIR=powerpc-apple-darwin8.11.0" "bindir=/usr/local/bin"
"datadir=/usr/local/share" "exec_prefix=/usr/local"
"includedir=/usr/local/include" "datarootdir=/usr/local/share"
"docdir=/usr/local/share/doc/" "infodir=/usr/local/share/info"
"pdfdir=/usr/local/sha
rm -f stage_current
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Bootstrap comparison failure!
gcc/cp/typeck.o differs
gcc/haifa-sched.o differs
gcc/real.o differs
gcc/tree-vectorizer.o differs
make[2]: *** [compare] Error 1
make[1]: *** [stage3-bubble] Error 2
make: *** [bootstrap] Error 2

real579m36.885s   - overnight delivery :)
user271m44.136s
sys 26m22.824s

Any idea what could be the problem and how to fix it? Should I just
run a simple "make"?

Csaba
Please CC me because I'm not subscribed to the mailing list. Thanks.
-- 
GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++
Life is complex, with real and imaginary parts.
"Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds
"People disagree with me. I just ignore them." -- Linus Torvalds

Re: GCC bootstrap mismatch on OS X 10.4

[Justin Mattock]

On Feb 13, 2011, at 1:01 AM, Csaba Raduly wrote:


Hi all,
I'm trying to build GCC (r170071) on powerpc-apple-darwin8.11.0 (a G4
Mac Mini with OS X 10.4.11). I built and installed gmp-5.0.1,
mpc-0.8.2 and mpfr-3.0.0, then ran

../gcc/configure --enable-languages=c,c++
make bootstrap



tough to say what darwin is asking for(*.h's/lib's) but normally gcc  
builds good

with these instructions here..:
http://cross-lfs.org/view/svn/
should have enough info for osx(-m32) in there..

This failed with:

libtool: link: /Users/useruser/GCC/build/./gcc/xgcc
-B/Users/useruser/GCC/build/./gcc/
-B/usr/local/powerpc-apple-darwin8.11.0/bin/
-B/usr/local/powerpc-apple-darwin8.11.0/lib/ -isystem
/usr/local/powerpc-apple-darwin8.11.0/include -isystem
/usr/local/powerpc-apple-darwin8.11.0/sys-include  -m64 -dynamiclib
-Wl,-fl
libtool: link: dsymutil .libs/libgomp.1.dylib || :
warning: no debug map in executable (-arch ppc64)
libtool: link: (cd ".libs" && rm -f "libgomp.dylib" && ln -s
"libgomp.1.dylib" "libgomp.dylib")
libtool: link: ar rc .libs/libgomp.a  alloc.o barrier.o critical.o
env.o error.o iter.o iter_ull.o loop.o loop_ull.o ordered.o parallel.o
sections.o single.o task.o team.o work.o lock.o mutex.o proc.o sem.o
bar.o ptrlock.o time.o fortran.o affinity.o
libtool: link: ranlib -c .libs/libgomp.a
libtool: link: ( cd ".libs" && rm -f "libgomp.la" && ln -s
"../libgomp.la" "libgomp.la" )
true  DO=all multi-do # make
make "DESTDIR=" "RPATH_ENVVAR=DYLD_LIBRARY_PATH"
"TARGET_SUBDIR=powerpc-apple-darwin8.11.0" "bindir=/usr/local/bin"
"datadir=/usr/local/share" "exec_prefix=/usr/local"
"includedir=/usr/local/include" "datarootdir=/usr/local/share"
"docdir=/usr/local/share/doc/" "infodir=/usr/local/share/info"
"pdfdir=/usr/local/sha
rm -f stage_current
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Bootstrap comparison failure!
gcc/cp/typeck.o differs
gcc/haifa-sched.o differs
gcc/real.o differs
gcc/tree-vectorizer.o differs
make[2]: *** [compare] Error 1
make[1]: *** [stage3-bubble] Error 2
make: *** [bootstrap] Error 2

real579m36.885s   - overnight delivery :)
user271m44.136s
sys 26m22.824s

Any idea what could be the problem and how to fix it? Should I just
run a simple "make"?

Csaba
Please CC me because I'm not subscribed to the mailing list. Thanks.
--
GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++
Life is complex, with real and imaginary parts.
"Ok, it boots. Which means it must be bug-free and perfect. " --  
Linus Torvalds

"People disagree with me. I just ignore them." -- Linus Torvalds



Justin P. Mattock

Re: Question about static code analysis features in GCC

[Richard Guenther]

On Sun, Feb 13, 2011 at 2:34 AM, sa...@hederstierna.com
 wrote:
> Hi
>
> I would like to have some advice regarding static code analysis and GCC.
> I've just reviewed several tools like Klocwork, Coverity, CodeSonar and 
> PolySpace.
> These tools offer alot of features and all tools seems to find different 
> types of defects.
> The tool that found most bugs on our code was Coverity, but it is also the 
> most expensive tool.
>
> But basically I would most like just to find very "simple" basic errors like 
> NULL-dereferences and buffer overruns.
> I attach a small example file with some very obvious errors like 
> NULL-dereferences and buffer overruns.
>
> This buggy file compiles fine though without any warnings at all with GCC as 
> expected
>
>    gcc -o example example.c -W -Wall -Wextra
>
> I tried to add checking with mudflap:
>
>    gcc -fmudflap -o example example.c -W -Wall -Wextra -lmudflap
>
> Then I found all defects in run-time, but I had to run the program so I could 
> not find all potential errors in compile-time.
> Also Valgrind could be used to check run-time bugs, but I'm not 100% sure I 
> can cover all execution paths in my tests (I also tried gcov).
>
> I tried to analyze my example file with CLANG, then I found "uninitialized" 
> issues and NULL-pointers, but not buffer overruns:
>
>    clang --analyze example.c
>    example.c:7:3: warning: Dereference of null pointer loaded from variable 
> 'a'
>    example.c:41:3: warning: Undefined or garbage value returned to caller
>
> About NULL-checks and buffer-overruns, is there any possible path to get such 
> checkers into a standard GCC, maybe in just some very limited level?
> I've checked the "MyGCC" (http://mygcc.free.fr) patch on Graphite, but it has 
> been rejected, could it be rewritten somehow as a standard opt_pass to just 
> find NULL-derefs?
>
> I've also checked TreeHydra in Mozilla project 
> (https://developer.mozilla.org/en/Treehydra) that gives JavaScript interface 
> to GIMPEL.
> Is the GCC4.5.x plugin API something that is recommended to use to implement 
> such features, is performance okey to not have it as a core opt-pass?
>
> I'm willing to put some free time into this matter if it turns out its 
> possible to add some tree SSA optimization pass that could find some limited 
> set of errors.
> Example given if some value is constant NULL and dereferenced, or some 
> element if accessed outside a constant length buffer using a constant index.
> What is your recommended path to move forward using GCC and basic static code 
> analysis?

It should be possible to fit static code analysis into GCC.  The most
prominent issue is that GCC is a compiler mainly looking at
optimization
quality, and optimization can defeat static code analysis in some
cases (such as aggressively using undefined behavior to do dead code
elimination).  On the other hand optimization makes static analysis
easier in some cases, and even more useful if issues in "really" dead
code
are removed.

As a way to start I would suggest to restrict static analysis to -O0
(no optimization), a suitable place to do such analysis is the first
entry in
the IPA pass pipeline (then you have the whole program in SSA, a
callgraph built and unused functions removed - you also have
always_inline
functions inlined).  Something that can be done quite easily is have a
mode for the standard SSA propagators (like constant propagation or
even value-numbering) to only compute the propagation but do no
modification to the program, if the results are then kept and not
freed
static analysis can use them.

I don't see a good reason to not include a well-desiged version
following that route into GCC itself.  Note that comparing to CLANG
this
analysis would reside in the middle-end, not the frontend - with the
advantage that it can take a look at the whole program when building
with link-time (non-)optimization and work cross-language.

No, I'm not going to implement it - but a patch that just inserts a
noop pass at the place I suggested should be < 50 lines of code.

Richard.

> About un-initialized values I found some additional info, it seems to be hard 
> to solve...
>  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501
>  http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-February/013170.html
>
> Thanks and Best Regards
> /Fredrik
>
> --
> #include 
>
> // Example1: null pointer de-reference
> int f1(void)
> {
>  int* a = NULL;
>  *a = 1;
>  return *a;
> }
>
> // Example2: buffer overrun global variable
> char v2[1];
> char* f2(void)
> {
>  v2[-1] = 1;
>  v2[0]  = 1;
>  v2[1]  = 1;
>  return (char*)v2;
> }
>
> // Example3: buffer overrun local variable
> int f3(void)
> {
>  char v3[1];
>  v3[-1] = 1;
>  v3[0]  = 1;
>  v3[1]  = 1;
>  return v3[-1] + v3[0] + v3[1] + v3[2];
> }
>
> // Example4: uninitialized memory access
> int f4(void)
> {
>  char v4[1];
>  return v4[0];
> }
>
> // Examples NULL dereference and buffer overr

Re: GCC bootstrap mismatch on OS X 10.4

[Justin Mattock]

On Feb 13, 2011, at 1:16 AM, Justin Mattock wrote:



On Feb 13, 2011, at 1:01 AM, Csaba Raduly wrote:


Hi all,
I'm trying to build GCC (r170071) on powerpc-apple-darwin8.11.0 (a G4
Mac Mini with OS X 10.4.11). I built and installed gmp-5.0.1,
mpc-0.8.2 and mpfr-3.0.0, then ran

../gcc/configure --enable-languages=c,c++
make bootstrap



tough to say what darwin is asking for(*.h's/lib's) but normally gcc  
builds good

with these instructions here..:
http://cross-lfs.org/view/svn/
should have enough info for osx(-m32) in there..

This failed with:

libtool: link: /Users/useruser/GCC/build/./gcc/xgcc
-B/Users/useruser/GCC/build/./gcc/
-B/usr/local/powerpc-apple-darwin8.11.0/bin/
-B/usr/local/powerpc-apple-darwin8.11.0/lib/ -isystem
/usr/local/powerpc-apple-darwin8.11.0/include -isystem
/usr/local/powerpc-apple-darwin8.11.0/sys-include  -m64 -dynamiclib
-Wl,-fl
libtool: link: dsymutil .libs/libgomp.1.dylib || :
warning: no debug map in executable (-arch ppc64)
libtool: link: (cd ".libs" && rm -f "libgomp.dylib" && ln -s
"libgomp.1.dylib" "libgomp.dylib")
libtool: link: ar rc .libs/libgomp.a  alloc.o barrier.o critical.o
env.o error.o iter.o iter_ull.o loop.o loop_ull.o ordered.o  
parallel.o

sections.o single.o task.o team.o work.o lock.o mutex.o proc.o sem.o
bar.o ptrlock.o time.o fortran.o affinity.o
libtool: link: ranlib -c .libs/libgomp.a
libtool: link: ( cd ".libs" && rm -f "libgomp.la" && ln -s
"../libgomp.la" "libgomp.la" )
true  DO=all multi-do # make
make "DESTDIR=" "RPATH_ENVVAR=DYLD_LIBRARY_PATH"
"TARGET_SUBDIR=powerpc-apple-darwin8.11.0" "bindir=/usr/local/bin"
"datadir=/usr/local/share" "exec_prefix=/usr/local"
"includedir=/usr/local/include" "datarootdir=/usr/local/share"
"docdir=/usr/local/share/doc/" "infodir=/usr/local/share/info"
"pdfdir=/usr/local/sha
rm -f stage_current
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Bootstrap comparison failure!
gcc/cp/typeck.o differs
gcc/haifa-sched.o differs
gcc/real.o differs
gcc/tree-vectorizer.o differs
make[2]: *** [compare] Error 1
make[1]: *** [stage3-bubble] Error 2
make: *** [bootstrap] Error 2

real579m36.885s   - overnight delivery :)
user271m44.136s
sys 26m22.824s

Any idea what could be the problem and how to fix it? Should I just
run a simple "make"?

Csaba
Please CC me because I'm not subscribed to the mailing list. Thanks.
--
GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++
Life is complex, with real and imaginary parts.
"Ok, it boots. Which means it must be bug-free and perfect. " --  
Linus Torvalds

"People disagree with me. I just ignore them." -- Linus Torvalds



Justin P. Mattock


 looking through seems gcc 4.6.0 is good using this..:
http://gcc.gnu.org/ml/gcc/2010-12/msg00459.html

but then again I have only used the clfs tutorials!!

hope this helps..

Justin P. Mattock

Re: X32 psABI status

[H.J. Lu]

On Sat, Feb 12, 2011 at 9:47 PM, Matt Thomas  wrote:
>
> On Feb 12, 2011, at 7:02 PM, Andrew Pinski wrote:
>
>> On Sat, Feb 12, 2011 at 3:04 PM, H. Peter Anvin  wrote:
>>> On 02/12/2011 01:10 PM, Florian Weimer wrote:
 Why is the ia32 compatiblity kernel interface used?
>>>
>>> Because there is no way in hell we're designing in a second
>>> compatibility ABI in the kernel (and it has to be a compatibility ABI,
>>> because of the pointer size difference.)
>>
>> I think he is asking why not create a new ABI layer for the kernel
>> like it is done for n32 for MIPS.
>
> The kernel syscall ABI needs to be able to be pass 64-bit quantities
> in a single register (since that's what the calling ABI is capable
> of doing but I don't think the ia32 kernel interface can do)?

It works. Please check out the x32 kernel to take a  look.

> Maybe it's me, but I expected X32 to be the X86-64 ABI with 32-bit longs
> and pointers (converted to 64-bit arguments when passed in register or
> on the stack).  That allows the same syscall argument marshalling that
> currently exists but just need a different set of syscall vectors.
>

That is exactly what we implemented.

-- 
H.J.

Re: X32 psABI status

[H.J. Lu]

On Sun, Feb 13, 2011 at 12:48 AM, Florian Weimer  wrote:
> * H. Peter Anvin:
>
>> On 02/12/2011 01:10 PM, Florian Weimer wrote:
>>> Why is the ia32 compatiblity kernel interface used?
>>
>> Because there is no way in hell we're designing in a second
>> compatibility ABI in the kernel (and it has to be a compatibility ABI,
>> because of the pointer size difference.)
>
> Actually, I'm wondering if you can do the translation in user space.
> There already are 32-on-64 implementations in existence, without
> kernel changes (recent Hotspot, LuaJIT, and probably some more).

Please check out the x32 kernel source and provide feedback.

-- 
H.J.

Re: X32 psABI status

[Florian Weimer]

* H. J. Lu:

>> Actually, I'm wondering if you can do the translation in user space.
>> There already are 32-on-64 implementations in existence, without
>> kernel changes (recent Hotspot, LuaJIT, and probably some more).
>
> Please check out the x32 kernel source and provide feedback.

I still don't understand why you need a separate syscall table.  You
should really be able to run on an unmodified amd64 kernel, in 64 bit
mode.  This would imply that tools like strace don't need any porting
at all (you could just use the amd64 version), and even GDB would
mostly worked unchanged.

Re: X32 psABI status

[H.J. Lu]

On Sun, Feb 13, 2011 at 7:07 AM, Florian Weimer  wrote:
> * H. J. Lu:
>
>>> Actually, I'm wondering if you can do the translation in user space.
>>> There already are 32-on-64 implementations in existence, without
>>> kernel changes (recent Hotspot, LuaJIT, and probably some more).
>>
>> Please check out the x32 kernel source and provide feedback.
>
> I still don't understand why you need a separate syscall table.  You
> should really be able to run on an unmodified amd64 kernel, in 64 bit

That is done on purpose. x32 is designed for environments where the
current ia32 API is sufficient. You can think it as ia32 with register
extended to 64bit plus 8 more registers. Everything else is still 32bit.

> mode.  This would imply that tools like strace don't need any porting
> at all (you could just use the amd64 version), and even GDB would
> mostly worked unchanged.
>

Yes, strace needs to be updated. I have ported GDB to x32.


-- 
H.J.

Re: X32 psABI status

[Florian Weimer]

* H. J. Lu:

> On Sun, Feb 13, 2011 at 7:07 AM, Florian Weimer  wrote:
>> * H. J. Lu:
>>
 Actually, I'm wondering if you can do the translation in user space.
 There already are 32-on-64 implementations in existence, without
 kernel changes (recent Hotspot, LuaJIT, and probably some more).
>>>
>>> Please check out the x32 kernel source and provide feedback.
>>
>> I still don't understand why you need a separate syscall table.  You
>> should really be able to run on an unmodified amd64 kernel, in 64 bit
>
> That is done on purpose. x32 is designed for environments where the
> current ia32 API is sufficient. You can think it as ia32 with register
> extended to 64bit plus 8 more registers. Everything else is still 32bit.

I think of it as amd64 where all the process memory happens to reside
in the first 4 GB of address space, and pointers are stored as 32 bits
(and you'd also reduce the size of longs because sizeof(long) !=
sizeof(void *) will break too many programs).

As I said, both LuaJIT and Hotspot are already using this model, with
custom memory allocators and a user-space translation layers, so I
still don't see what you get by changing the kernel.  LuaJIT has even
implemented the amd64 ABI, so you can call C libraries from your
32-bit code.  (Note that LuaJIT uses 64-bit words to store 32-bit
pointers with several tag bits, but it does so even on pure 32-bit
platforms.)

If you want to make x32 closer to i386, I don't see the point.  Why
would it be problematic if it was as close to i386 as, say, armel?

Re: X32 psABI status

[H.J. Lu]

On Sun, Feb 13, 2011 at 7:21 AM, Florian Weimer  wrote:
> * H. J. Lu:
>
>> On Sun, Feb 13, 2011 at 7:07 AM, Florian Weimer  wrote:
>>> * H. J. Lu:
>>>
> Actually, I'm wondering if you can do the translation in user space.
> There already are 32-on-64 implementations in existence, without
> kernel changes (recent Hotspot, LuaJIT, and probably some more).

 Please check out the x32 kernel source and provide feedback.
>>>
>>> I still don't understand why you need a separate syscall table.  You
>>> should really be able to run on an unmodified amd64 kernel, in 64 bit
>>
>> That is done on purpose. x32 is designed for environments where the
>> current ia32 API is sufficient. You can think it as ia32 with register
>> extended to 64bit plus 8 more registers. Everything else is still 32bit.
>
> I think of it as amd64 where all the process memory happens to reside
> in the first 4 GB of address space, and pointers are stored as 32 bits
> (and you'd also reduce the size of longs because sizeof(long) !=
> sizeof(void *) will break too many programs).

That is what the processor sees in an x32 program.

> As I said, both LuaJIT and Hotspot are already using this model, with
> custom memory allocators and a user-space translation layers, so I
> still don't see what you get by changing the kernel.  LuaJIT has even
> implemented the amd64 ABI, so you can call C libraries from your
> 32-bit code.  (Note that LuaJIT uses 64-bit words to store 32-bit
> pointers with several tag bits, but it does so even on pure 32-bit
> platforms.)

They can continue to do so.

> If you want to make x32 closer to i386, I don't see the point.  Why
> would it be problematic if it was as close to i386 as, say, armel?
>

We are providing a 32bit API with 64bit registers. Current APIs support
either 32bit or 64bit.  I am not talking about pointer or long. I am talking
other types, like time_t, off_t, ..., defined by API.  Adding another API
is extremely difficult.

-- 
H.J.

Re: X32 psABI status

[Maciej W. Rozycki]

On Sun, 13 Feb 2011, Florian Weimer wrote:

> >> Actually, I'm wondering if you can do the translation in user space.
> >> There already are 32-on-64 implementations in existence, without
> >> kernel changes (recent Hotspot, LuaJIT, and probably some more).
> >
> > Please check out the x32 kernel source and provide feedback.
> 
> I still don't understand why you need a separate syscall table.  You
> should really be able to run on an unmodified amd64 kernel, in 64 bit
> mode.  This would imply that tools like strace don't need any porting
> at all (you could just use the amd64 version), and even GDB would
> mostly worked unchanged.

 For the record -- I suggested a similar approach for n32 MIPS too (back 
when it was on the table), but people rejected it deciding it was easier 
for them to add a separate syscall table (for a change).  It was perhaps 
even more surprising as any MIPS 32-bit user pointer is a valid 64-bit one 
too (I suspect this is also the case with x86-64) and any simple type, 
including pointers and the "long long" type (such as used with lseek64(2), 
etc.) goes into a single 64-bit register or stack slot with both ABIs, so 
any conversion layer (boundary checks or whatever; structures can be 
sorted out with padding) in libc would be pretty thin.

 One argument in favour was the need of some people for crippled 
interfaces such as original lseek(2) that would fail on large files for 
the sake of some broken programs out there they wanted to rebuild for the 
new ABI without fixing, sigh...  Actually some OSes, such as NetBSD (I 
think, it could have been one of the other *BSDs), do not offer these 
crippled interfaces at all on any platform, but I gather people simply are 
not particularly interested into pushing portability that far.

 So now we have another table in the kernel to maintain that goes wrong in 
respect to the two others from time to time.  But there you go...  At 
least each of the three is optional.  I couldn't care less about n32 
anyway; I usually configure 64-bit MIPS kernels for n64 only.

  Maciej

Re: X32 psABI status

[H.J. Lu]

On Sun, Feb 13, 2011 at 7:43 AM, Maciej W. Rozycki  wrote:
> On Sun, 13 Feb 2011, Florian Weimer wrote:
>
>> >> Actually, I'm wondering if you can do the translation in user space.
>> >> There already are 32-on-64 implementations in existence, without
>> >> kernel changes (recent Hotspot, LuaJIT, and probably some more).
>> >
>> > Please check out the x32 kernel source and provide feedback.
>>
>> I still don't understand why you need a separate syscall table.  You
>> should really be able to run on an unmodified amd64 kernel, in 64 bit
>> mode.  This would imply that tools like strace don't need any porting
>> at all (you could just use the amd64 version), and even GDB would
>> mostly worked unchanged.
>
>  For the record -- I suggested a similar approach for n32 MIPS too (back
> when it was on the table), but people rejected it deciding it was easier
> for them to add a separate syscall table (for a change).  It was perhaps
> even more surprising as any MIPS 32-bit user pointer is a valid 64-bit one
> too (I suspect this is also the case with x86-64) and any simple type,
> including pointers and the "long long" type (such as used with lseek64(2),
> etc.) goes into a single 64-bit register or stack slot with both ABIs, so
> any conversion layer (boundary checks or whatever; structures can be
> sorted out with padding) in libc would be pretty thin.

x32 is the same 64bit kernel interface for system calls which takes 64bit
arguments.  You can pass either 32bit or 64bit value to them.

-- 
H.J.

Re: X32 psABI status

[Petr Baudis]

On Sun, Feb 13, 2011 at 07:13:57AM -0800, H.J. Lu wrote:
> On Sun, Feb 13, 2011 at 7:07 AM, Florian Weimer  wrote:
> > * H. J. Lu:
> >
> >>> Actually, I'm wondering if you can do the translation in user space.
> >>> There already are 32-on-64 implementations in existence, without
> >>> kernel changes (recent Hotspot, LuaJIT, and probably some more).
> >>
> >> Please check out the x32 kernel source and provide feedback.
> >
> > I still don't understand why you need a separate syscall table.  You
> > should really be able to run on an unmodified amd64 kernel, in 64 bit
> 
> That is done on purpose. x32 is designed for environments where the
> current ia32 API is sufficient. You can think it as ia32 with register
> extended to 64bit plus 8 more registers. Everything else is still 32bit.

I think it would be great if you could add some text like this plus some
rationale (AIUI, this is geared mainly at new Atoms and other x86_64
embedded platforms) to the document.

(BTW, it is not really convincing to me that such a niche is worth all
the trouble this is going to bring.)

-- 
Petr "Pasky" Baudis
Computer science education cannot make an expert programmer any more
than studying brushes and pigment can make an expert painter. --esr

Re: X32 psABI status

[H.J. Lu]

2011/2/13 Petr Baudis :
> On Sun, Feb 13, 2011 at 07:13:57AM -0800, H.J. Lu wrote:
>> On Sun, Feb 13, 2011 at 7:07 AM, Florian Weimer  wrote:
>> > * H. J. Lu:
>> >
>> >>> Actually, I'm wondering if you can do the translation in user space.
>> >>> There already are 32-on-64 implementations in existence, without
>> >>> kernel changes (recent Hotspot, LuaJIT, and probably some more).
>> >>
>> >> Please check out the x32 kernel source and provide feedback.
>> >
>> > I still don't understand why you need a separate syscall table.  You
>> > should really be able to run on an unmodified amd64 kernel, in 64 bit
>>
>> That is done on purpose. x32 is designed for environments where the
>> current ia32 API is sufficient. You can think it as ia32 with register
>> extended to 64bit plus 8 more registers. Everything else is still 32bit.
>
> I think it would be great if you could add some text like this plus some
> rationale (AIUI, this is geared mainly at new Atoms and other x86_64
> embedded platforms) to the document.

I updated:

https://sites.google.com/site/x32abi/

> (BTW, it is not really convincing to me that such a niche is worth all
> the trouble this is going to bring.)
>

That is a good question.  Otherwise x32 would have been implemented
long time ago.


-- 
H.J.

Re: GCC bootstrap mismatch on OS X 10.4

[Jonathan Wakely]

On 13 February 2011 09:01, Csaba Raduly wrote:
>
> Any idea what could be the problem and how to fix it? Should I just
> run a simple "make"?

Questions about using or building gcc should be sent to
gcc-h...@gcc.gnu.org, not this list, please follow up there instead,
thanks.

I don't know if it will solve your problem, but yes, you just build
gcc with 'make' these days, not 'make bootstrap'

Re: X32 psABI status

[Joseph S. Myers]

On Sun, 13 Feb 2011, Petr Baudis wrote:

> I think it would be great if you could add some text like this plus some
> rationale (AIUI, this is geared mainly at new Atoms and other x86_64
> embedded platforms) to the document.
> 
> (BTW, it is not really convincing to me that such a niche is worth all
> the trouble this is going to bring.)

It seems to me there's a much more general utility for this.  After all, 
the normal practice on 64-bit Power Architecture GNU/Linux systems, say, 
is for most programs to be 32-bit and only a few that have a use for a 
large address space to be 64-bit.  For most programs, large pointers and 
size_t are just a waste of memory (and so of cache) - but the extra 
registers are significantly beneficial (as are such things as being able 
to assume SSE to be supported).  (Large files, 64-bit time_t, etc., 
however, are of wider use than large address space, but as I noted in 
 it would be a fairly 
substantial project to address all such issues of inappropriate arbitrary 
limits in C APIs.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: GCC bootstrap mismatch on OS X 10.4

[Jack Howarth]

On Sun, Feb 13, 2011 at 05:27:37PM +, Jonathan Wakely wrote:
> On 13 February 2011 09:01, Csaba Raduly wrote:
> >
> > Any idea what could be the problem and how to fix it? Should I just
> > run a simple "make"?
> 
> Questions about using or building gcc should be sent to
> gcc-h...@gcc.gnu.org, not this list, please follow up there instead,
> thanks.
> 
> I don't know if it will solve your problem, but yes, you just build
> gcc with 'make' these days, not 'make bootstrap'

  I suspect his problems will be solved by adding --with-dwarf2 to the
configure options. We don't seem to have a specific PR for this but I
believe there are bootstrap comparision failures in libgomp for darwin8
using stabs. We don't get a lot of testing on darwin8 theses days since
the regress Apple tester is now on darwin9 (plus this could be intel
specific). Both Mike and Iain have access to darwin8 so we hopefully can
get a PR opened.
  Jack
ps I had suggested awhile back that we default darwin8 to dwarf2 but Mike 
thinks the dwarf2 support is too immature in the Xcode for darwin8 to 
safely do that.

GCC 4.6.0 Status Report (2011-02-13)

[Joseph S. Myers]

Status
==

Trunk is in Stage 4, for regression fixes and documentation fixes.

The numbers of regressions have continued to go down since the
previous report, but more work is still needed especially on the P1
regressions.  User-visible improvements relative to 4.5 should also be
documented in gcc-4.6/changes.html if not already mentioned there.
Once the P1 regressions have been resolved and no P3 regression
appears to merit classifying as P1, the 4.6 branch and a first release
candidate can be created.  Maintainers are reminded of the importance
of being conservative in what patches go in until then.

Quality Data


Priority  # Change from Last Report
--- ---
P19 -  1
P2   93 -  8
P3   10 - 11
--- ---
Total   112 - 20

Previous Report
===

http://gcc.gnu.org/ml/gcc/2011-01/msg00343.html

The next report for 4.6.0 will be sent by Richard.

-- 
Joseph S. Myers
jos...@codesourcery.com

gcc-4.3-20110213 is now available

[gccadmin]

Snapshot gcc-4.3-20110213 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20110213/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch 
revision 170110

You'll find:

 gcc-4.3-20110213.tar.bz2 Complete GCC (includes all of below)

  MD5=002300dfb8e170cdc924b224544b69d0
  SHA1=59075f0a2a1f4215251e585f2abd2ed6c403ce23

 gcc-core-4.3-20110213.tar.bz2C front end and core compiler

  MD5=5c5fe4f92c58f12ca808fc9a5574be0e
  SHA1=aeac8eeb9650d0b115777e4f35dc97098d095429

 gcc-ada-4.3-20110213.tar.bz2 Ada front end and runtime

  MD5=6791bc9d13993f903f02117addfce676
  SHA1=08764f4ecf512fb602f5ffc8e98fe96c26104f07

 gcc-fortran-4.3-20110213.tar.bz2 Fortran front end and runtime

  MD5=20409f22c46b66fcb175b212ff8fde3a
  SHA1=b316d79768d9e781aab172e9590cc8a8111b169e

 gcc-g++-4.3-20110213.tar.bz2 C++ front end and runtime

  MD5=12d3a5fc137a2b69472ec9a7e741c607
  SHA1=323a0743915d72effa44f0677596f45e82810c26

 gcc-go-4.3-20110213.tar.bz2  Go front end and runtime

  MD5=60a0366a84e08768e1fad881decbb038
  SHA1=97803f1310bc7d93236471f339f805b1cfa335c9

 gcc-java-4.3-20110213.tar.bz2Java front end and runtime

  MD5=c37c0e4e8cfbe0c0b94ef08bce1fc2ea
  SHA1=c93d826a0767bc5155bed6c3a32ee1ccf38ad151

 gcc-objc-4.3-20110213.tar.bz2Objective-C front end and runtime

  MD5=a7794b9d98478481a2b390b5a8df66d7
  SHA1=e03645fb3a64aeebd6339265d7b9d6376a5eae43

 gcc-testsuite-4.3-20110213.tar.bz2   The GCC testsuite

  MD5=2a214e495468741977226f331e1ab8ba
  SHA1=2841f390985d92a69ad202f8553435bcf4ce62f7

Diffs from 4.3-20110206 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.3
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: X32 psABI status

[Arnd Bergmann]

On Saturday 12 February 2011 20:41:01 H.J. Lu wrote:
> Hi,
> 
> We made lots of progresses on x32 pABI:
> 
> https://sites.google.com/site/x32abi/
> 
> 1. Kernel interface with syscall is close to be finalized.

Really? I haven't seen this being posted for review yet ;-)

The basic concept looks entirely reasonable to me, but I'm
curious what drove the decision to start out with the x86_64
system calls instead of the generic ones.

Since tile was merged, we now have support for compat syscalls
in the generic syscall ABI. I would have assumed that it
was possible to just use those if you decide to do a new
ABI in the first place.

The other option that would have appeared natural to me is
to just use the existing 32 bit compat ABI with the few
necessary changes done based on the personality.

Arnd

Re: X32 psABI status

[H.J. Lu]

On Sun, Feb 13, 2011 at 12:10 PM, Arnd Bergmann  wrote:
> On Saturday 12 February 2011 20:41:01 H.J. Lu wrote:
>> Hi,
>>
>> We made lots of progresses on x32 pABI:
>>
>> https://sites.google.com/site/x32abi/
>>
>> 1. Kernel interface with syscall is close to be finalized.
>
> Really? I haven't seen this being posted for review yet ;-)
>
> The basic concept looks entirely reasonable to me, but I'm
> curious what drove the decision to start out with the x86_64
> system calls instead of the generic ones.
>
> Since tile was merged, we now have support for compat syscalls
> in the generic syscall ABI. I would have assumed that it
> was possible to just use those if you decide to do a new
> ABI in the first place.
>
> The other option that would have appeared natural to me is
> to just use the existing 32 bit compat ABI with the few
> necessary changes done based on the personality.
>

If you are interested, please check out the x32 kernel to
take a look and provide feedback.

Thanks.

-- 
H.J.

Re: X32 psABI status

[H. Peter Anvin]

On 02/13/2011 01:10 PM, H.J. Lu wrote:
>>>
>>> 1. Kernel interface with syscall is close to be finalized.
>>

I don't think calling it "finalized" is accurate... it is more
accurately described as "prototyped".

>> Really? I haven't seen this being posted for review yet ;-)
>>
>> The basic concept looks entirely reasonable to me, but I'm
>> curious what drove the decision to start out with the x86_64
>> system calls instead of the generic ones.
>>
>> Since tile was merged, we now have support for compat syscalls
>> in the generic syscall ABI. I would have assumed that it
>> was possible to just use those if you decide to do a new
>> ABI in the first place.
>> 
>> The other option that would have appeared natural to me is
>> to just use the existing 32 bit compat ABI with the few
>> necessary changes done based on the personality.

The actual idea is to use the i386 compat ABI for memory layout, but
with a 64-bit register convention.  That means that system calls that
don't make references to memory structures can simply use the 64-bit
system calls, otherwise we're planning to reuse the i386 compat system
calls, but invoke them via the syscall instruction (which requires a new
system call table) and to pass 64-bit arguments in single registers.

-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: X32 psABI status

[H.J. Lu]

On Sun, Feb 13, 2011 at 1:16 PM, H. Peter Anvin  wrote:
> On 02/13/2011 01:10 PM, H.J. Lu wrote:
>>> The basic concept looks entirely reasonable to me, but I'm
>>> curious what drove the decision to start out with the x86_64
>>> system calls instead of the generic ones.
>>>
>>> Since tile was merged, we now have support for compat syscalls
>>> in the generic syscall ABI. I would have assumed that it
>>> was possible to just use those if you decide to do a new
>>> ABI in the first place.
>>>
>>> The other option that would have appeared natural to me is
>>> to just use the existing 32 bit compat ABI with the few
>>> necessary changes done based on the personality.
>
> The actual idea is to use the i386 compat ABI for memory layout, but
> with a 64-bit register convention.  That means that system calls that
> don't make references to memory structures can simply use the 64-bit
> system calls, otherwise we're planning to reuse the i386 compat system
> calls, but invoke them via the syscall instruction (which requires a new
> system call table) and to pass 64-bit arguments in single registers.
>

That is is currently implemented on hjl/x32 branch.

I also added

__NR_sigaction
__NR_sigpending
__NR_sigprocmask
__NR_sigsuspend

to help the Bionic C library.


-- 
H.J.

Re: X32 psABI status

[Alan Cox]

> The actual idea is to use the i386 compat ABI for memory layout, but
> with a 64-bit register convention.  That means that system calls that
> don't make references to memory structures can simply use the 64-bit
> system calls, otherwise we're planning to reuse the i386 compat system
> calls, but invoke them via the syscall instruction (which requires a new
> system call table) and to pass 64-bit arguments in single registers.

Who actually needs this new extra API - whats the justification for
everyone having more crud dumping their kernels, more syscall paths
(which are one of the most security critical areas) and the like.

What are the benchmark numbers to justify this versus just using the
existing kernel interfaces ?

Alan

Re: X32 psABI status

[H. Peter Anvin]

On 02/13/2011 01:28 PM, H.J. Lu wrote:
> 
> That is is currently implemented on hjl/x32 branch.
> 
> I also added
> 
> __NR_sigaction
> __NR_sigpending
> __NR_sigprocmask
> __NR_sigsuspend
> 
> to help the Bionic C library.
> 

That seems a little redundant... even on the i386 front we want people
to use the rt_sig* system calls.  As a porting aid I can see it, but we
should avoid deprecated system calls in the final version.

-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: X32 psABI status

[H.J. Lu]

On Sun, Feb 13, 2011 at 2:03 PM, H. Peter Anvin  wrote:
> On 02/13/2011 01:28 PM, H.J. Lu wrote:
>>
>> That is is currently implemented on hjl/x32 branch.
>>
>> I also added
>>
>> __NR_sigaction
>> __NR_sigpending
>> __NR_sigprocmask
>> __NR_sigsuspend
>>
>> to help the Bionic C library.
>>
>
> That seems a little redundant... even on the i386 front we want people
> to use the rt_sig* system calls.  As a porting aid I can see it, but we
> should avoid deprecated system calls in the final version.
>

That is the plan. I don't want to spend more time on fixing the
Bionic C library. Once x32 glibc is running, I will remove those
ia32 system calls.

-- 
H.J.

Re: X32 psABI status

[H. Peter Anvin]

On 02/13/2011 01:16 PM, H. Peter Anvin wrote:
> 
> The actual idea is to use the i386 compat ABI for memory layout, but
> with a 64-bit register convention.  That means that system calls that
> don't make references to memory structures can simply use the 64-bit
> system calls, otherwise we're planning to reuse the i386 compat system
> calls, but invoke them via the syscall instruction (which requires a new
> system call table) and to pass 64-bit arguments in single registers.
> 

Oh, and as to why not copy the i386 system call list straight off... we
don't really want to add a new ABI with crap like sys_socketcall.

-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: X32 psABI status

[Arnd Bergmann]

On Sunday 13 February 2011, H. Peter Anvin wrote:
> The actual idea is to use the i386 compat ABI for memory layout, but
> with a 64-bit register convention.  That means that system calls that
> don't make references to memory structures can simply use the 64-bit
> system calls, otherwise we're planning to reuse the i386 compat system
> calls, but invoke them via the syscall instruction (which requires a new
> system call table) and to pass 64-bit arguments in single registers.

As far as I know, any task can already call both the 32 and 64 bit syscall
entry points on x86. Is there anything you can't do just as well by
using a combination of the two methods, without introducing a third one?

Arnd

Re: X32 psABI status

[H. Peter Anvin]

On 02/13/2011 02:28 PM, Arnd Bergmann wrote:
> On Sunday 13 February 2011, H. Peter Anvin wrote:
>> The actual idea is to use the i386 compat ABI for memory layout, but
>> with a 64-bit register convention.  That means that system calls that
>> don't make references to memory structures can simply use the 64-bit
>> system calls, otherwise we're planning to reuse the i386 compat system
>> calls, but invoke them via the syscall instruction (which requires a new
>> system call table) and to pass 64-bit arguments in single registers.
> 
> As far as I know, any task can already call both the 32 and 64 bit syscall
> entry points on x86. Is there anything you can't do just as well by
> using a combination of the two methods, without introducing a third one?

We prototyped using the int $0x80 system call entry point.  However,
there are two disadvantages:

a. the int $0x80 instruction is much slower than syscall.  An actual
   i386 process can use the syscall instruction which is disambiguated
   by the CPU based on mode, but an x32 process is in the same CPU mode
   as a normal 64-bit process.
b. 64-bit arguments have to be split between two registers for the
   i386 entry points, requiring user-space stubs.

All in all, the cost of an extra system call table is quite modest.  The
cost of an entire different ABI layer (supporting a new memory layout)
would be enormous, a.k.a. "not worth it", which is why the memory layout
of kernel objects needs to be compatible with i386.

-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: gcc 4.5.2-6 - internal compiler: Segmentation fault

[David C. Rankin]

On 02/13/2011 01:31 AM, Eric Botcazou wrote:
>>  I figured if I knew what was needed before opening the bug it would cut
>> down on the need-info requests. Thanks.
> 
> The instructions are available on the http://gcc.gnu.org/bugs/ page.
> 

Thank you Eric,

I've tried to include everything. If I missed anything (not sure about 
what all
sourced were neede), just ask and I'll get whatever else is needed:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47723

-- 
David C. Rankin, J.D.,P.E.

Re: X32 psABI status

[Arnd Bergmann]

On Sunday 13 February 2011, H. Peter Anvin wrote:
> We prototyped using the int $0x80 system call entry point.  However,
> there are two disadvantages:
> 
> a. the int $0x80 instruction is much slower than syscall.  An actual
>i386 process can use the syscall instruction which is disambiguated
>by the CPU based on mode, but an x32 process is in the same CPU mode
>as a normal 64-bit process.

Well, you could simply change entry.S to allow syscall with high numbers
to have the same effect as int $0x80, but not introduce another table
to solve this.

> b. 64-bit arguments have to be split between two registers for the
>i386 entry points, requiring user-space stubs.

64 bit arguments are very rare, and most of those syscalls are not
performance critical, so this could be dealt with on a case-by-case
basis, possibly by introducing a new syscall number for the variant
passing a 64 bit register.

> All in all, the cost of an extra system call table is quite modest.

The memory size overhead may be small, but auditing another table
for every change could become a noticable burden (your though, not mine).

> The cost of an entire different ABI layer (supporting a new memory layout)
> would be enormous, a.k.a. "not worth it", which is why the memory layout
> of kernel objects needs to be compatible with i386.

Right, this makes sense, you certainly can't redefine all the data
structures. 

What would probably be a good idea is to compare the set of syscalls
in X32 and asm-generic, and to either eliminate or document the
differences. You can probably even take the asm-generic syscall numbers,
even if you keep the i386 data structures.

Arnd

Re: X32 psABI status

[H.J. Lu]

On Sun, Feb 13, 2011 at 2:57 PM, Arnd Bergmann  wrote:
>
>> The cost of an entire different ABI layer (supporting a new memory layout)
>> would be enormous, a.k.a. "not worth it", which is why the memory layout
>> of kernel objects needs to be compatible with i386.
>
> Right, this makes sense, you certainly can't redefine all the data
> structures.
>
> What would probably be a good idea is to compare the set of syscalls
> in X32 and asm-generic, and to either eliminate or document the
> differences. You can probably even take the asm-generic syscall numbers,
> even if you keep the i386 data structures.
>

x32 system call number is BASE + 64bit system call number.  It is
easy to keep 64bit and x32 in sync.

-- 
H.J.

Re: X32 psABI status

[Alan Cox]

> a. the int $0x80 instruction is much slower than syscall.  An actual
>i386 process can use the syscall instruction which is disambiguated
>by the CPU based on mode, but an x32 process is in the same CPU mode
>as a normal 64-bit process.

So set a flag, whoopee

> b. 64-bit arguments have to be split between two registers for the
>i386 entry points, requiring user-space stubs.

Diddums. Given you've yet to explain why everyone desperately needs this
extra interface why do we care ?

> All in all, the cost of an extra system call table is quite modest.

And the cost of not doing it is a gloriously wonderful zero. Yo've still
not explained the justification or what large number of apps are going to
use it.

It's a simple question - why do we care, why do we want the overhead and
the hassle, what do users get in return ?

Alan

Re: X32 psABI status

[H.J. Lu]

On Sun, Feb 13, 2011 at 3:39 PM, Alan Cox  wrote:
>> a. the int $0x80 instruction is much slower than syscall.  An actual
>>    i386 process can use the syscall instruction which is disambiguated
>>    by the CPU based on mode, but an x32 process is in the same CPU mode
>>    as a normal 64-bit process.
>
> So set a flag, whoopee
>
>> b. 64-bit arguments have to be split between two registers for the
>>    i386 entry points, requiring user-space stubs.
>
> Diddums. Given you've yet to explain why everyone desperately needs this
> extra interface why do we care ?
>
>> All in all, the cost of an extra system call table is quite modest.
>
> And the cost of not doing it is a gloriously wonderful zero. Yo've still
> not explained the justification or what large number of apps are going to
> use it.
>
> It's a simple question - why do we care, why do we want the overhead and
> the hassle, what do users get in return ?
>

The real question is if we need to use ia32.  If the answer is yes, then
x32 provides the benefit of ia32 with register extended to 64bit plus 8
more registers as well as IP relative address.

-- 
H.J.

Re: X32 psABI status

[H. Peter Anvin]

On 02/13/2011 01:33 PM, Alan Cox wrote:


Who actually needs this new extra API - whats the justification for
everyone having more crud dumping their kernels, more syscall paths
(which are one of the most security critical areas) and the like.

What are the benchmark numbers to justify this versus just using the
existing kernel interfaces ?



That's what the prototype is meant to show.

-hpa

Re: X32 psABI status

[H. Peter Anvin]

On 02/13/2011 03:39 PM, Alan Cox wrote:

a. the int $0x80 instruction is much slower than syscall.  An actual
i386 process can use the syscall instruction which is disambiguated
by the CPU based on mode, but an x32 process is in the same CPU mode
as a normal 64-bit process.


So set a flag, whoopee


That's what we're doing, functionally.


b. 64-bit arguments have to be split between two registers for the
i386 entry points, requiring user-space stubs.


Diddums. Given you've yet to explain why everyone desperately needs this
extra interface why do we care ?


All in all, the cost of an extra system call table is quite modest.


And the cost of not doing it is a gloriously wonderful zero. Yo've still
not explained the justification or what large number of apps are going to
use it.

It's a simple question - why do we care, why do we want the overhead and
the hassle, what do users get in return ?


The target applications are an embedded (closed or mostly closed) 
environment, and the question is if the performance gain is worth it. 
It is an open question at this stage and we'll see what the numbers look 
like and, if it turns out to be worthwhile, what exactly the final 
implementation will look like.


-hpa