On Tue, Apr 3, 2012 at 3:49 AM, Ilya Enkovich <enkovich....@gmail.com> wrote:
>> On 3/04/2012, at 2:16 AM, Ilya Enkovich wrote:
>>>> 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?
>> It's simpler that you think.  The target headers ($tm_file in config.gcc -- 
>> gnu-user.h, linux*.h, etc. in this case) are all included into tm.h, which 
>> serves as proxy to all those headers.  All definitions made in preceding 
>> headers are available in subsequent headers.  So, given that 
>> i386/gnu-user*.h precedes i386/linux*.h in config.gcc's $tm_file, you only 
>> need to touch linux*.h.
>> Thanks,
>> --
>> Maxim Kuvyrkov
>> CodeSourcery / Mentor Graphics
> Hi,
> I prepared version with common linux.h and gnu-user.h. Does it look OK?
> Bootstrapped and checked on linux-x86_64.

There are so many duplicates in gnu-user64.h and gnu-user32.h.
Please move all of them to gnu-user.h.



Reply via email to