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
> linux64.h. Right?

I think it is a good idea.



Reply via email to