Re: Defined symbols requiring an other library

Re: Defined symbols requiring an other library

[Nick Clifton]

Hi Kurt,

> Does anybody know if there will be other things that might be a problem
> we have doing this?

I suspect that you might encounter similar problems with dynamic relocs for 
other targets, not just the COPY reloc.  (I do not have proof of this, but it 
seems reasonable, since ABIs vary from target to target).

> Or is there a better of doing this?

Wouldn't it be easier to use the loader to resolve this problem for you ?  ie 
have the loader perform a dry run and tell you exactly where it found all the 
symbols ?  (You may need to add code to the loader in order to do this, or you 
may be able to use a tool like strace or systemtap).  Or you could look at the 
prelinker and possibly parse prelinked binaries ?  (The point being that these 
tools already know how to resolve dynamic relocs and find libraries, so why not 
make use of them).

Cheers
  Nick

Re: Defined symbols requiring an other library

[Kurt Roeckx]

On Wed, Jan 09, 2008 at 04:28:55PM +0000, Nick Clifton wrote:
> Hi Kurt,
> 
> > Does anybody know if there will be other things that might be a problem
> > we have doing this?
> 
> I suspect that you might encounter similar problems with dynamic relocs for 
> other targets, not just the COPY reloc.  (I do not have proof of this, but it 
> seems reasonable, since ABIs vary from target to target).
> 
> > Or is there a better of doing this?
> 
> Wouldn't it be easier to use the loader to resolve this problem for you ?  ie 
> have the loader perform a dry run and tell you exactly where it found all the 
> symbols ?  (You may need to add code to the loader in order to do this, or you 
> may be able to use a tool like strace or systemtap).  Or you could look at the 
> prelinker and possibly parse prelinked binaries ?  (The point being that these 
> tools already know how to resolve dynamic relocs and find libraries, so why not 
> make use of them).

Atleast prelink is not very portable.  It only seems to be available on:
Architecture: alpha amd64 i386 powerpc ppc64

systemtap has a simular problem:
Architecture: i386 amd64 ia64 s390 powerpc arm armel armeb

Changing the dynamic loader might be a good way to do this.


Kurt

Re: Defined symbols requiring an other library

[Daniel Jacobowitz]

On Thu, Jan 10, 2008 at 01:45:06AM +0100, Kurt Roeckx wrote:
> Changing the dynamic loader might be a good way to do this.

The dynamic loader features used by prelink are probably all you
need.  There's no documentation of them, though.

-- 
Daniel Jacobowitz
CodeSourcery

Defined symbols requiring an other library.

[Kurt Roeckx]

Hi,

In Debian we recently started to track all the symbols that a library
provides.  This comes down to listing all the defined symbols
in a library, except some special cases.

When we link some other binary we look at the undefined symbols it has
and then look which from the libraries it has a DT_NEEDED entry for
provides those symbols.  We use this to see what the minumum version
requirement of that library we should use.

We found a problem with this method.  If there is a copy relocation
for the symbol it ends up as a defined symbol in the .bss, while the
real symbol is actually in an other library.  So it needs that library
but we currently don't see it.

Mips and mipsel seem to be the only arches in Debian that do not have
copy relocations, and those symbols end up as undefined there as
expected.

So we now plan to change it so that defined symbols that also have a
copy relocation are threated as undefined symbols.  

Does anybody know if there will be other things that might be a problem
we have doing this?  Or is there a better of doing this?

We basicly need a list of symbols that a library provides and a list of
symbols that are provided by an other library.


Kurt