This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Wed, 6 Dec 2006, Daniel Jacobowitz wrote: > I don't think MV's kernel is any different in this area, but I'm > not authoritative. I am. > > You pass your old-ABI compiler the option -mabi=aapcs-linux, which works > > fine with my gcc 4.1 old-ABI toolchain and is exactly what mainline 2.6 > > does. > > I don't recommend doing this. The two compilers (...gnu-gcc > -mabi=aapcs-linux and ...gnueabi-gcc) do not have exactly the same > configuration; I don't know for sure what might be different between > them, but I do know we only expect EABI compliance from the EABI > compilers. -mabi=aapcs-linux versus -mabi=aapcs was mainly for > interoperation between arm-none-eabi-gcc and > arm-none-linux-gnueabi-gcc. In fact, the kernel doesn't care much about EABI full compliance. The only requirement on the kernel to be able to run EABI userspace is to have the same structure member alignment and function argument layout as the "true" EABI compliance so the kernel and user space understand each other across syscall boundaries. And using -mabi=aapcs worked just fine for that so far regardless of the gcc config. If that behavior was not to hold true then gcc should not accept the conflicting -mabi argument. But that would be unfortunate if it happened. Nicolas -- For unsubscribe information see http://sourceware.org/lists.html#faq
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |