This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: PATCH [1/n]: Initial x32 support
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 15 Mar 2012 20:39:44 +0000 (UTC)
- Subject: Re: PATCH [1/n]: Initial x32 support
- References: <20120315181727.GB21802@intel.com>
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