This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Symbol versioning question..
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Andreas Schwab <schwab at linux-m68k dot org>
- Cc: Marcus Shawcroft <marcus dot shawcroft at linaro dot org>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 19 Jul 2013 17:09:04 +0000
- Subject: Re: Symbol versioning question..
- References: <CABXK9ndVsUhXdx5YfV+NDSa99daV9wJtj1ucMAxcH6zQmbChqg at mail dot gmail dot com> <877ggmzmg9 dot fsf at igel dot home>
On Fri, 19 Jul 2013, Andreas Schwab wrote:
> One problem with the abi check is that there is currently no check that
> all expected interfaces are actually present in the abi lists, which has
> biten us in the past already (like the absence of fallocate64 on all
> 32-bit archs in 2.10).
That should only now cause problems for
(a) new architectures missing an interface;
(b) existing bugs with missing interfaces that were already missing as of
2.16;
(c) for Hurd, hppa and am33, whose maintainers have yet to add ABI test
baselines (and am33 is very bitrotten anyway).
Any new issues with a *new* interface such as fallocate64 being missing
should be caught because the patch adding such an interface should update
all the abilist files (at least, it's strongly recommended to update them
all, including in ports). The ABI tests were thoroughly bitrotten and not
being used at the time of 2.10.
Now, for detecting issues under (a) and (b), I don't see this as an *ABI*
test issue but an *API* one - the ABI tests check for changes to previous
symbol versions on existing architectures and that's exactly what they are
meant to do, and checking that a particular public interface - an API - is
present is a different matter. This is
<http://sourceware.org/glibc/wiki/Development_Todo/Master#Untested_interfaces.>.
Even if you can't test that an interface works, I think it's still
worthwhile to test that calls to it compile and link without warnings,
e.g.
volatile int run_test = 0;
int
do_test (void)
{
/* This interface needs root access to run, so we only test that
calls to it compile and link. */
if (run_test)
call_the_interface (arguments);
return 0;
}
Of course, some tests would need to be Linux-specific if they test
Linux-specific interfaces. But that's not a problem; there's already a
Linux-specific sysdeps/unix/sysv/linux/tst-clone.c, added to tests for an
appropriate subdirectory in sysdeps/unix/sysv/linux/Makefile, for example.
(In many cases you may be able to test an interface works but only on a
recent-enough kernel, for example. In that case, a failure with ENOSYS
should make the test print a message and return success, while other
unexpected conditions should make the test fail.)
Individual such extra tests are of course welcome, as are lists of
untested interfaces or tools to detect such interfaces.
> Generally, once a version is released the ABI is frozen, no further
> additions or changes are possible. So the only option you have is to
> make sure that there will be no mount@GLIBC_2.17 on aarch64 and add it
> to GLIBC_2.18. To do that you need to move the symbol out of the
> generic Versions files into more specific ones that are not seen by
> aarch64.
As far as I know it should be possible with appropriate versioned_symbol
magic, as was done with alpha __sqrtl_finite (bug 15666).
--
Joseph S. Myers
joseph@codesourcery.com