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? Thank you, -- Maxim Kuvyrkov CodeSourcery / Mentor Graphics