| Summary: | gnat-gcc-4.1.1 fails to install | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Michael Dillon <mike> |
| Component: | Current packages | Assignee: | ada team [OBSOLETE] <ada+disabled> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | dirk.heinrichs |
| Priority: | High | ||
| Version: | 2006.0 | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Michael Dillon
2006-07-21 10:40:40 UTC
/me too Quick update: ebuild /usr/portage/dev-lang/gnat-gcc-4.1.1.ebuild qmerge will complete the installation. Yes, of course, but this is not even a workaround but rather a portage trickery. You could have also used FEATURES=-strict emerge ... A few words on this problem - this is a QA violation, but this is something that comes from upstream and which we need to seriously investigate and which is not critical for Ada. In fact executable stack is a common way to implement nested functions - which are absent in C standard but are very important in Ada. As such the fix involved is not going to be easy and, actually, I am personally not even sure how to approach this. A developer from hardened project (Kevin Quinn?) has promised to help, but well, this is a low priority for all of us as it is and thus is unlikely to be "fixed" soon. George (In reply to comment #3) > As such the fix involved is not going to be easy and, actually, I am > personally not even sure how to approach this. A developer from hardened > project (Kevin Quinn?) has promised to help, but well, this is a low priority > for all of us as it is and thus is unlikely to be "fixed" soon. Yes; unfortunately I have too much other stuff that's higher priority. My aim was to eliminate the execstack requirement, but that's a big-ish job. You can add a "QA_EXECSTACK" definition to the ebuild, to prevent the FEATURES="stricter" check failing (for hardened use there's an override). Simply set it to a whitespace-separated list of files, relative to ${D}, that will fail. I'm pretty sure you can use wildcards, so: QA_EXECSTACK="usr/*/gnat-gcc-bin/4.1/gnatbind usr/*/gnat-gcc-bin/4.1/gnatmake usr/*/gnat-gcc-bin/4.1/gnatls usr/lib/gnat-gcc/*/4.1/adalib/libgnat-4.1.so usr/libexec/gnat-gcc/*/4.1/gnat1" should do the trick. The '*' matches the CTARGET, e.g. i686-pc-linux-gnu, which obviously changes depending on which arch you're building - although note that some arches may not need execstack. In detail, the problem for GNAT occurs when use is made of a GNAT extension (attribute Unrestricted_Access) which allows, amongst other things, nested subprograms to be called out of scope yet still access data from the scope of their declaration (rather than the scope of the call). gcc implements these with trampolines (small pieces of code generated at run-time on the stack), as it's pretty much the only way to do it for the permissive C language semantics without changing what a function pointer looks like (you'd have to change a subprogram pointer into a record of two pointers; one to the subprogram and one to the declaration scope). Normal Ada rules on scoping of subprogranm access types mean that they cannot be used in different scope to the subprogram - this means that the compiler always knows where the nested subprogram scope is with respect to the call, and so it's possible to deal with it without generating a trampoline. This explains how Ada works fine on embedded systems with non-executable RAM. However GNAT uses 'Unrestricted_Access to do exactly that - propogate subprogram pointers out of scope, in particular when it uses its Sort subprograms (which cannot be done the same way with standard Ada - the Ada way would be to have them as generics) - so you get trampolines and hence the execstack marking. It's dangerous, in that you could write silly code that would be meaningless; for example if you saved such a pointer then tried to access it later when it was no longer in any scope. See http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gnat_rm/Unrestricted_005fAccess.html#Unrestricted_005fAccess gnat-gpl-3.4.6.2006 and gnat-gcc-4.1.x are marked with QA_EXECSTACK. Interestingly the gnat-gcc-4.2.0 that I just added to the tree did not trigger any execstack complaints. Lets hope there is no need to do so in future versions as well! I'll check/update the gnat-gcc-3.4 series and then close this bug. George all gnat compilers were marked with QA_EXECSTACK. Closing. |
