> On 2/04/2012, at 3:23 AM, Ilya Enkovich wrote: > >>> As is, it appears this patch did not see much testing, I'm pretty sure it >>> breaks building shared libraries and PIE executable for Linux. >> >> I do not expect any changes in compiler behavior for non Android >> targets. I bootstrapped and checked patched compiler on linux-x86_64. >> I also built ptched compiler for Android target using NDK scripts. > > OK. > >>> >>> Here and in other instances below you use "GNU_USER_TARGET_" prefix. I >>> would prefer using a shorter "GNU_USER_" instead unless there is a good >>> reason to add "TARGET" too. >> >> The reason is that some macroses are defined in other files and I just >> redefine them (i.e. GNU_USER_TARGET_CC1_SPEC). This prefix is also >> used for other targets (i.e. in linux-eabi.h). So I do not see a good >> reason to change it everywhere or mix it with other prefix >> "GNU_USER_". > > OK. > >>> Here you remove "%{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s". >>> Presumably, you are moving that to GNU_USER[_TARGET]_ENDFILE_SPEC, but you >>> never define it. >> >> You are right. It is in GNU_USER_TARGET_ENDFILE_SPEC which is defined >> in gcc/config/gnu-user.h. > > OK. I missed that GNU_USER_TARGET_ENDFILE_SPEC was already defined. > >> >>> >>>> >>>> /* A C statement (sans semicolon) to output to the stdio stream >>>> FILE the assembler definition of uninitialized global DECL named >>>> diff --git a/gcc/config/i386/linux.h b/gcc/config/i386/linux.h >>>> index 73681fe..a832ddc 100644 >>>> --- a/gcc/config/i386/linux.h >>>> +++ b/gcc/config/i386/linux.h >>> >>> i386/linux.h is used only for simple x86 32-bit builds; i386/linux64.h is >>> used for multilib-enabled x86 toolchains. Placing below definitions in >>> i386/linux.h will not allow adding an Android as an additional multilib to >>> -m32/-m64 x86 builds. I improve on this situation I suggest: >>> - rename i386/linux.h to i386/linux32.h (with corresponding change to >>> config.gcc), >>> - put below definitions to new i386/linux.h (remember to add license notice >>> header to the new file), >>> - include i386/linux.h from both i386/linux32.h and i386/linux64.h. >> >> Android does not support x86_64 target and therefore I do not want >> -mandroid support for this target. When Android supports x86_64 target >> this change would be appropriate. > > The point is that one can build a toolchain for i686-linux-gnu that will > support both 32-bit and 64-bit multilibs. The 32-bit multilib will be used > by default, and compilation for 64-bit user-space can be requested with -m64 > option. Even though Android is not supported for -m64, such a toolchain can > support Android as a additional "-m32 -mandroid" multilib. I.e., the > toolchain will have three multilibs in total: "-m32" (default), "-m64" and > "-m32 -mandroid". I386/linux64.h will be picked up for such a toolchain, > even though by default it would compile for 32-bit target. Does this clear > up things? >
I think I see your point. And it seems to make all this work I'll also have to rename i386/gnu-user.h into i386/gnu-user32.h and create i386/gnu-user.h with common definitions to be included by gnu-user[32|64].h. Otherwise I wont be able to use some definitions (i.e. GNU_USER_TARGET_LINK_SPEC and GNU_USER_TARGET_MATHFILE_SPEC) in linux64.h. Right? Thanks, Ilya > Thank you, > > -- > Maxim Kuvyrkov > CodeSourcery / Mentor Graphics >