This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: PATCH: Move sysdeps/x86_64/Implies to sysdeps/x86_64/64
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Roland McGrath <roland at hack dot frob dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Sun, 8 Apr 2012 07:44:54 -0700
- Subject: Re: PATCH: Move sysdeps/x86_64/Implies to sysdeps/x86_64/64
- References: <20120322175315.GA9938@intel.com><20120322195022.F2EF32C07C@topped-with-meat.com><CAMe9rOriXXrVWVLLuES8OUAXvbcVgcJEAYAgJjHWr3YCB2JmaQ@mail.gmail.com><CAMe9rOru6EXRsoqaBKS0a9fGqwey+52DCak0MwGPM1bzWf29NQ@mail.gmail.com><20120322204013.868A12C086@topped-with-meat.com><CAMe9rOq87mKXdoMOGH=cxiq8C6qhK7bTi5bAB9jQk_Eg7x72Vw@mail.gmail.com><20120322210647.330402C07E@topped-with-meat.com><CAMe9rOpiAWE8U2XFxgavJBi9FUomTZh3XEwcdYN59qNBR8OM7g@mail.gmail.com><20120322211655.C5E992C07E@topped-with-meat.com><CAMe9rOp7AVVWn_Bo6sKC7yRuCaRxiqUXGpLCm9wqvg2aSjHx-Q@mail.gmail.com><20120322220155.1AC112C07E@topped-with-meat.com><CAMe9rOqj3J=fw984tRMG-FTgxgxbKbjRZJzrnoaOfqzAi815+g@mail.gmail.com><20120322222523.5F52A2C08D@topped-with-meat.com><CAMe9rOqqKB0g_0xoueMWX-902eOeFqpw3LmO7Ej6p=xERjWtCQ@mail.gmail.com><20120406210447.642DE2C0C4@topped-with-meat.com><CAMe9rOo1gPRVRqhTwYjwdhKWyTgn2-aJMsLnHw7ZYZjPDnGiJw@mail.gmail.com><Pine.LNX.4.64.1204071511060.12109@digraph.polyomino.org.uk>
On Sat, Apr 7, 2012 at 8:19 AM, Joseph S. Myers <joseph@codesourcery.com> wrote:
> On Fri, 6 Apr 2012, H.J. Lu wrote:
>
>> For x86-64, with Implies-after, the search order can only be
>>
>> ieee754/ldbl-96
>> ieee754/dbl-64/wordsize-64
>> ieee754/dbl-64
>> ieee754/flt-32
>> wordsize-64
>>
>> not
>>
>> wordsize-64
>> ieee754/ldbl-96
>> ieee754/dbl-64/wordsize-64
>> ieee754/dbl-64
>> ieee754/flt-32
>
> Thanks for giving a concrete different in orders. ?The next question is:
> why does that difference matter for x32? ?(If it doesn't, you need to give
> an example of a case where the order *does* matter and you can't get the
> order you want.)
It does matter for both x32 and x86-64. I created hjl/order branch and
moved wordsize-64 to sysdeps/x86_64/64/Implies:
http://sourceware.org/git/?p=glibc.git;a=commit;h=66446deaf4c8828ed49ccfd359c2027484f25507
Now the search order for x86-64 becomes:
nptl/sysdeps/unix/sysv/linux/x86_64 sysdeps/unix/sysv/linux/x86_64
sysdeps/unix/sysv/linux/wordsize-64 nptl/sysdeps/unix/sysv/linux
nptl/sysdeps/pthread sysdeps/pthread sysdeps/unix/sysv/linux
sysdeps/gnu sysdeps/unix/common sysdeps/unix/mman sysdeps/unix/inet
nptl/sysdeps/unix/sysv sysdeps/unix/sysv sysdeps/unix/x86_64
nptl/sysdeps/unix sysdeps/unix sysdeps/posix sysdeps/x86_64/64
sysdeps/wordsize-64 sysdeps/x86_64/fpu/multiarch sysdeps/x86_64/fpu
sysdeps/x86_64/multiarch nptl/sysdeps/x86_64 sysdeps/x86_64
sysdeps/ieee754/ldbl-96 sysdeps/ieee754/dbl-64/wordsize-64
sysdeps/ieee754/dbl-64 sysdeps/ieee754/flt-32 sysdeps/ieee754
sysdeps/generic
Please note that sysdeps/wordsize-64 is searched before
sysdeps/x86_64. We have
./bits/wordsize.h
./sysdeps/unix/sysv/linux/sparc/bits/wordsize.h
./sysdeps/unix/sysv/linux/powerpc/bits/wordsize.h
./sysdeps/x86_64/bits/wordsize.h
./sysdeps/s390/s390-64/bits/wordsize.h
./sysdeps/s390/s390-32/bits/wordsize.h
./sysdeps/sparc/sparc32/bits/wordsize.h
./sysdeps/sparc/sparc64/bits/wordsize.h
./sysdeps/powerpc/powerpc64/bits/wordsize.h
./sysdeps/powerpc/powerpc32/bits/wordsize.h
./sysdeps/wordsize-32/bits/wordsize.h
./sysdeps/wordsize-64/bits/wordsize.h
./sysdeps/wordsize-64/bits/wordsize.h is used instead of
./sysdeps/x86_64/bits/wordsize.h. I need a way to place
sysdeps/x86_64 before sysdeps/wordsize-64 in search
order when wordsize-64 is in sysdeps/x86_64/64/Implies.
> My guess is that "wordsize-64" is being used for more than one thing, and
> should actually be split up; some files may be for "64-bit operations are
> efficient", some for "long and long long are both 64-bit", some for
> "dirent64 is the same as dirent". ?If we can distinguish the various ways
> "wordsize-64" is used, then x32 could use a different subset of the new
> directories from pure 64-bit.
That will help x32, which has files like
[hjl@gnu-6 glibc-x32]$ cat sysdeps/unix/sysv/linux/x86_64/x32/scandir64.c
#include <sysdeps/wordsize-64/scandir64.c>
[hjl@gnu-6 glibc-x32]$
Thanks.
--
H.J.