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: Symbol versioning question..


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


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