This is the mail archive of the libc-ports@sources.redhat.com mailing list for the libc-ports 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 1a/9] Tilera (and Linux asm-generic) support for glibc


On Sat, 5 Nov 2011, Chris Metcalf wrote:

> >> +  GLIBC_2.12 {
> >> +    # name requested by gcc community.
> >> +    __mcount;
> >> +  }
> > GLIBC_2.12 does not make sense for a new symbol being introduced in 2.15; 
> > GLIBC_2.15 would be appropriate.
> 
> In the version we're releasing to customers (our upcoming 4.0 release) we
> are based on RHEL 6 with their glibc 2.12, so we'll need to keep the symbol
> at 2.12 for that.  Does it therefore make sense for us to use the same
> value in the sources we're returning to the community?  We can certainly do
> it either way.

It's certainly possible to include 2.15 versions in a backport to 2.12; at 
most you may need to backport some versions to libc's Versions.def.  
However:

> I think we would like to be binary compatible with our 4.0 customer
> release.  I hadn't noticed shlib-versions before!  In any case we seem to
> match all the defaults:

Most of those defaults are generically fine; it's the defaulting to having 
backwards binary compatibility for every old glibc version back to 2.0 
that doesn't make sense for new ports.

> .*-.*-linux.*           libm=6
> .*-.*-linux.*           libc=6
> .*-.*-.*                ld=ld.so.1
> .*-.*-.*                libdl=2
> etc.
> 
> But it sounds like you're saying we should have a
> ports/sysdeps/tile/shlib-versions with just the single "DEFAULT" line
> specifying GLIBC_2.15 (or GLIBC_2.12 depending on what makes sense).  Is
> that right?

Yes.  Like sysdeps/arm/shlib-versions does for arm.*-.*-linux-gnueabi.* 
(GLIBC_2.4) or sysdeps/m68k/coldfire/shlib-versions (also GLIBC_2.4).

Backporting a use of 2.15 in this bit to 2.12 would be trickier.  The 
problems would be:

* symbols existing with different definitions in 2.12 or an older version, 
and 2.13 or a newer version, where symbol versioning causes old binaries 
or shared libraries to get the old version and new ones to get the new 
version; simply using a DEFAULT of 2.15 in 2.12 sources would mean you get 
binaries expecting the old version but with the 2.15 version number, which 
is bad (I don't know what if any symbols are affected);

* symbols that have been removed after 2.12 so that old binaries or shared 
libraries can continue to use them but new ones can't; using a DEFAULT of 
2.15 in 2.12 would mean that binaries built with your 2.12 would expect 
those symbols still to be present in 2.15, but a real 2.15 wouldn't have 
them at all, which is also bad (this affects at least the RPC symbols for 
which new binaries are meant to use libtirpc).

So if you want compatibility with binaries built against 2.12-based 
sources, using a DEFAULT of 2.12 is probably safer (and still avoids 
having any unnecessary binary compatibility with versions 2.0 to 2.11), 
and given that I suppose you may as well use 2.12 for the explicit 
versions in your Versions files as well.  (The 2.11 version I commented on 
in sysdeps/unix/sysv/linux/generic/wordsize-32/Versions should still be 
2.15, however; if necessary, override it just for your target.)

There is one more thing you can do in that case: declare that versions 
2.13 and 2.14 did not exist for these targets, and do what 
sysdeps/mips/shlib-versions does (for 2.1 in its case) to eliminate the 
corresponding symbol versions.  So you'd have symbols for GLIBC_2.12 
(anything introduced up to 2.12 and still present in that version), 
GLIBC_2.15 (anything introduced in 2.13, 2.14 and 2.15 and still present 
in 2.15) and the later versions, but not GLIBC_2.13 and GLIBC_2.14.  This 
might not actually eliminate any compatibility code (I don't know if there 
was anything introduced in 2.13 or 2.14 but eliminated by 2.15) but is 
logically correct.

> install a new gcc as well.  So perhaps we could use __sync builtins for now
> where it makes sense, and leave the rest of the atomic support the way it is? 

Seems plausible, although I don't know how well current glibc actually 
supports being built by 4.4.

> >> diff --git a/sysdeps/tile/bits/byteswap.h b/sysdeps/tile/bits/byteswap.h
> > There's nothing *wrong* with this file; it just seems:
> >
> > * probably unnecessary (current GCC can detect bswap patterns that should 
> > include those used by the generic bits/byteswap.h);
> >
> > * generic (it would be better to make libc's bits/byteswap.h use the 
> > built-ins if __GNUC_PREREQ (4, 3).
> 
> Apparently our gcc port does not recognize these patterns (I just checked);

It looks like bswap detection was added in r148471 (2009-06-14), so for 
4.5 (whereas __builtin_bswap* came in in 4.3).  (So a change to the 
generic file will make things better for users of 4.3 and 4.4 - as 
compilers used with installed glibc, that is - this is an installed header 
- not just compilers used to build glibc - and make no difference for 4.5 
and later.)

Arguably the existing target-specific byteswap.h headers would best also 
use the built-in functions for new-enough GCC (presuming that GCC knows 
how to generate the appropriate instruction sequences for those 
architectures) rather than the various inline asms etc. presently used - 
but that's obviously a matter for the relevant target maintainers (m68k, 
i386, ia64, s390, x86_64).

> > Using __builtin_signbit / __builtin_signbitf would seem better than code 
> > using unions (though it ought to expand the same).
> 
> I wasn't aware of these; they must have been introduced after gcc 4.4. 

No, they were introduced in 4.0.  A 4.4 compiler really ought to have no 
problems expanding those built-in functions....

> This feels like the answer should be the same as the __atomic_* stuff,
> perhaps, i.e. maybe try to change all the platforms at once to do an
> #include_next based on __GNUC_PREREQ?

This is an installed header, so #include_next won't work so well.  A 
proper solution based on a fix to GCC PR 36757 *would* use __GNUC_PREREQ 
(directly in math.h where signbit is defined).

> Interesting thought!  I assume I would do something like the following?
> 
> tilegx)
>   base_machine=tile
>   case $($CC $CFLAGS $CPPFLAGS -dM -E -xc /dev/null | grep SIZEOF_POINTER) in
>   *8) machine=tile/tilegx/tilegx64 ;;
>   *4) machine=tile/tilegx/tilegx32 ;;
>   esac ;;

Yes.

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