[Vm-dev] Warning, warning.. new danger!
siguctua at gmail.com
Fri Jan 17 18:59:24 UTC 2014
On 17 January 2014 19:03, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> Hi Igor,
> On Fri, Jan 17, 2014 at 5:02 AM, Igor Stasenko <siguctua at gmail.com> wrote:
>> "The GCC devs decided to unilaterally change the Linux x86 ABI  
>>  . I'm not sure when this happened, but I think it first became a
>> common problem with GCC 4.1. Previously the Linux x86 ABI was the "SysV
>> i386 ABI", which stated that the stack is aligned to a 4-byte boundary on
>> function entry. GCC now assumes by default that the stack is aligned to a
>> 16-byte boundary. This is an very controversial issue with the GCC devs
>> saying they have changed the ABI, and many other people considering the
>> SysV ABI to be the real ABI and GCC to be buggy. GCC Bugzilla is full of
>> flamewars. GCC devs have said "GCC chose to change the *unwritten*standard for the ABI in use for IA32 GNU/Linux" and "The ABI is
>> undocumented; that is reality" "
>> basically, it affects everything which dealing with generated code.
>> like JIT/FFI.
>> Now it explains why NB started crashing on never versions of ubuntu,
>> while worked well before.
> But Mac OS X has had 16-byte alignment for the entirety of Mac OS X on
> x86. And so Cog has used 16-byte alignment on linux also for a long time
> now. I don't think this is too much of a departure from the SysV i386
> ABI. A change in what registers are callee-saved, what register is the
> result register etc would be disastrous. There are other changes which
> would be welcome too, such as returning float results through SSE registers
> instead of though the, frankly obsolete, x87 stack. So I don't think this
> is cause to throw up one's hands, Robbie style ;-)
> i am quite neutral about what ABI to use..
i just don't like that there is no some official way to determine what
a binary compatible with .. therefore i forced to assume worst and use most
pessimistic ABI model. :(
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev