[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Symbol-based dependencies on shared libraries: some news

On Sat, 04 Aug 2007, Steve Langasek wrote:
> On Sat, Aug 04, 2007 at 10:41:25PM +0200, Raphael Hertzog wrote:
> > On Sat, 04 Aug 2007, Loïc Minier wrote:
> > >  Do you strip the "well known symbols" you've seen on each arch so that
> > >  one only has to specify the other symbols?
> > No, because they might change with the toolchain and we want to track that
> > properly...
> Why does it need tracking?  If these symbols were to disappear that would
> be no loss, it shouldn't be relevant to the library ABIs at all.  I think it
> would indeed be better to exclude these symbols from the list.

Somehow I always thought that the executables were using those symbols.
If that's not the case, and if they are only used by the internal
machinery (i.e. none of those symbols actually appear undefined in objdump's
output of a program), then I'll happily strip them from the symbols file.

That exclude list will still have to be maintained over the years I think
since the list will probably evolve.

I'm checking for example on a powerpc machine:

/bin/ls:     file format elf32-powerpc

10025168      DF *UND*  00000010  GLIBC_2.0   readlink
10025170      DF *UND*  00000154  GLIBC_2.0   getgrnam
1001136c g    DF .text  0000003c  Base        _restgpr_18
10025178      DF *UND*  0000003c  GLIBC_2.2   __fpending
10011444 g    DF .text  00000014  Base        _restgpr_31_x
1001138c g    DF .text  0000001c  Base        _restgpr_26
100112f8 g    DF .text  00000018  Base        _savegpr_27
10011384 g    DF .text  00000024  Base        _restgpr_24
10011424 g    DF .text  00000034  Base        _restgpr_23_x

So it looks like those symbols are defined in each and every binary.
But the programs do not rely on the same symbols from the libraries.
Thus it seems fine to exclude them from the symbols files.

Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :

Reply to: