This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH [1/n]: Initial x32 support


On Thu, 15 Mar 2012, H.J. Lu wrote:

> 1. Introduce data-machine to override "$(config-machine) $(base-machine)"
> when checking for C++ type data.  config-machine and base-machine for x32
> are x86_64.  But its C++ type data is different from x86_64.

This can already be overridden with $(abi-name) - ports has its own 
c++-types and localplt files for "powerpcsoft-linux-gnu" (the target 
triplets are powerpc-*-linux-gnu as for hard-float; the C++ types are the 
same as for hard-float, but the localplt data is different); I see I 
haven't got round to setting this up for MIPS (which has three ABIs before 
you get into hard/soft float and endian differences) but it should work in 
such cases just the same.  Put an ABI entry in the x32 shlib-versions 
file.

>    e. Enable sysdeps/x86_64/lib-names.awk and sysdeps/x86_64/stubs-biarch.h
>       so that we can properly generate <gnu/lib-names.h> and <gnu/stubs.h>

It seems to me like these should be able to use the same set of conditions 
as used for bits/syscall.h to handle an arbitrary number of variants.  
Maybe rename the variables used for that from syscall-list-* to 
multiarch-header-* or similar, move them out of sysdeps/unix/sysv/linux/ 
to non-OS-specific directories and use the same set of conditions in the 
generated headers?  That is, if syscall-list-variants (under its new name) 
says "32bit 64bit" then <gnu/lib-names.h> and <gnu/stubs.h> would have 
conditions to include -32bit and -64bit versions, and the #if conditions 
would be as in syscall-list-32bit-condition and 
syscall-list-64bit-condition.

> 	* configure.in: Add sysdeps preconfigure fragment support.

The principle of having such a fragment is good, but I think you're 
running them too late.  I think you should run sysdeps preconfigure 
fragments (all of them) from libc at around the same time they are run for 
add-ons.  This allows libc targets to look more like ports ones in that 
the code

# Expand the configuration machine name into a subdirectory by architecture
# type and particular chip.  If an add-on configure fragment already set
# base_machine, we don't change it.

no longer need hardcode lots of architecture details in the toplevel 
configure.in; I'd rather that the cases for each architecture were in a 
sysdeps preconfigure fragment.

-- 
Joseph S. Myers
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]