Re: [RFC] make gdb handle weak function better

[Hui Zhu <teawater at gmail dot com>]

On Thu, Aug 12, 2010 at 04:31, Daniel Jacobowitz <dan@codesourcery.com> wrote:
> 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.
>

That will be the best.  But looks need a big update.

#0  lookup_symbol (name=0xbfe59b30 "memset", block=0x9ac4138,
domain=VAR_DOMAIN, is_a_field_of_this=0x0)
    at ../../src/gdb/symtab.c:1091
During symbol reading, DW_AT_name missing from DW_TAG_base_type.
During symbol reading, unsupported tag: 'DW_TAG_const_type'.
#1  0x0839febf in find_imps (symtab=0x0, block=0x9ac4138,
method=0x94aa3ba "memset", syms=0x0, nsym=0xbfe59c68,
    ndebug=0xbfe59c64) at ../../src/gdb/objc-lang.c:1331
#2  0x082f4592 in decode_objc (argptr=0xbfe59f14, funfirstline=1,
file_symtab=0x0, canonical=0xbfe59ef4,
    saved_arg=0x94aa3ba "memset") at ../../src/gdb/linespec.c:1145
#3  0x082f3c45 in decode_line_1 (argptr=0xbfe59f14, funfirstline=1,
default_symtab=0x9ac4248, default_line=24,
    canonical=0xbfe59ef4, not_found_ptr=0xbfe59ee0) at
../../src/gdb/linespec.c:777
#4  0x082aa5e5 in parse_breakpoint_sals (address=0xbfe59f14,
sals=0xbfe59ebc, addr_string=0xbfe59ef4,
    not_found_ptr=0xbfe59ee0) at ../../src/gdb/breakpoint.c:7250
#5  0x082aa7f0 in do_captured_parse_breakpoint (ui=0x95a9398,
data=0xbfe59e98) at ../../src/gdb/breakpoint.c:7320
#6  0x08312b38 in catch_exception (uiout=0x95a9398, func=0x82aa7b8
<do_captured_parse_breakpoint>,
    func_args=0xbfe59e98, mask=6) at ../../src/gdb/exceptions.c:468
#7  0x082aaea4 in create_breakpoint (gdbarch=0x9a814c8, arg=0x94aa3ba
"memset", cond_string=0x0, thread=0,
    parse_condition_and_thread=1, tempflag=0,
type_wanted=bp_breakpoint, ignore_count=0,
    pending_break_support=AUTO_BOOLEAN_AUTO, ops=0x0, from_tty=1,
enabled=1) at ../../src/gdb/breakpoint.c:7502
#8  0x082ab5aa in break_command_1 (arg=0x94aa3ba "memset", flag=0,
from_tty=1) at ../../src/gdb/breakpoint.c:7723
#9  0x082ab745 in break_command (arg=0x94aa3ba "memset", from_tty=1)
at ../../src/gdb/breakpoint.c:7795

Do you have some good idea on it?

Thanks,
Hui


> --
> Daniel Jacobowitz
> CodeSourcery
>