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, Mar 15, 2012 at 1:39 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> 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.

Thanks for the pointer.  I made the change.

>> ? ?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

Where should they go? sysdeps/generic?

> 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.

I will see what I can do.

>> ? ? ? * 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.
>

I moved it before add-ons.

I will post separate patches tomorrow.

Thanks for your inputs.


-- 
H.J.


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