Re: [RFC] make gdb handle weak function better

[Daniel Jacobowitz <dan@codesourcery.com>]

On Wed, Aug 11, 2010 at 09:04:44AM +0100, Chris January wrote:
> I don't think this is right. My understanding is that the linker
> (ld-linux) doesn't keep searching other shared libraries if it finds a
> weak symbol. So the search order is as follows:
> 1. 'strong' calloc in libc.so.6.
> 2. 'weak' calloc in libc.so.6.
> 3. 'strong' calloc in ld-linux.so.2.
> 4. 'weak' calloc in ld-linux.so.2.

There won't be both a strong and weak symbol in the same library; not
from the point of view of ld.so.  There may be in the static symbol
table (.symtab) but only one will end up in .dynsym/.hash/.gnu_hash.

But the important point is this one:

> Notice that a 'weak' calloc in libc trumps any definition of calloc in
> ld-linux.

This is correct.

> The problem with gdb is that it search the shared libraries in the order
> they were loaded - notice info sharedlibrary gave you ld-linux first
> instead of libc - so gdb incorrectly picks ld-linux's calloc. As a
> general heuristic gdb should instead start looking for symbols in the
> most recently loaded shared library (i.e. objfile) (after the main
> executable) and work backwards. This doesn't necessarily match the
> dynamic linker's behaviour exactly, but it gets pretty close for little
> effort.

That makes sense, although it may be system-specific.  Even better
would be to revisit our support for multiple-location breakpoints.
"break calloc" ought to stop on every instance of calloc.

-- 
Daniel Jacobowitz
CodeSourcery