AMD64 version of GNAT Ada compiler broken due to libthr

[John Marino]

Ah, interesting.  I didn't realize the ramifications of AMD64-only 
application of mprotect().  It's easy enough to apply the same macro to 
both architectures.

As far as pushing it upstream, I've got literally a few dozen patches, 
and the majority of them should be contributed back.  I haven't gone 
through the absurdly difficult and time-consuming process of assigning 
copyright over to the FSF, partly because I reside in France with a 
Dutch employer and nobody I work for would sign the legal documents FSF 
requests (if I even wanted to share with my employers what I do in my 
own time.)

I may go through the process some day if we can leave my employers out 
of it, but it's not a priority at this moment.  I'm not philosophically 
opposed to giving back, although I am dismayed at the number of offered 
patches that are never reviewed by the gcc developers and die on the 
vine.  If I could find a way to "fast-track" these patches in where I 
wouldn't be wasting my time, I'd do it.  It's a pain to maintain a 
parallel fork and I'd love to reduce the number of differences between 
the code bases.

Obviously if you have any ideas that get my FreeBSD work into the gcc 
efficiently, I'm all ears.

Regards,
John


Kostik Belousov wrote:
> On Fri, Dec 31, 2010 at 08:37:14PM +0100, John Marino wrote:
>> Hi Kostik,
>>
>> Thanks for pointing me in the right direction.  After some research, I 
>> discovered that only DragonFly BSD allows execution on the stack by 
>> default.  NetBSD and OpenBSD (and Solaris and Darwin) all were specially 
>> configured within gcc to execute mprotect first to enable this 
>> functionality.  FreeBSD never had this gcc configuration code and 
>> frankly it looks like it should have already been there.
>>
>> I created my own __enable_execute_stack macro function based on these 
>> previous works and now GNAT has passed all tests!  Since i386 always 
>> worked, I only applied to macro to the AMD64 configuration header.
> You need the same application of mprotect() for i386 too, since
> 32bit binary executed on amd64 kernel gets non-executable stack as well.
> 
>> You've been a great help!  Once I understood what the issue was, 
>> everything fell into place.
> Will you upstream the changes to gcc ?
>