On Mon, Apr 2, 2012 at 7:16 AM, Ilya Enkovich <enkovich....@gmail.com> wrote: >> 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? >
I think it is a good idea. Thanks. -- H.J.