[RFC] make gdb handle weak function better

[RFC] make gdb handle weak function better

[Hui Zhu]

Hi,

I meet following trouble:
cat 1.c
int
main ()
{
	calloc (3, 1);
}
gcc -g 1.c
gdb ./a.out
(gdb) start
Temporary breakpoint 1 at 0x8048385: file 1.c, line 4.
Starting program: /home/teawater/gdb/bgdbno/gdb/a.out

Temporary breakpoint 1, main () at 1.c:4
4		calloc (3, 1);
(gdb) b calloc
During symbol reading, incomplete CFI data; unspecified registers
(e.g., eax) at 0x8048382.
Breakpoint 2 at 0xb7ff82a6
(gdb) info sharedlibrary
From        To          Syms Read   Shared Object Library
0xb7fe47f0  0xb7ff97df  Yes (*)     /lib/ld-linux.so.2
0xb7e80230  0xb7f80ea4  Yes (*)     /lib/tls/i686/cmov/libc.so.6
(*): Shared library is missing debugging information.
(gdb) c
Continuing.

Program exited with code 010.

The inferior is not break because gdb set breakpoint in the weak
function calloc in lib/ld-linux.so.2.
But the inferior call the calloc in /lib/tls/i686/cmov/libc.so.6.

And I check the lookup_symbol and lookup_minimal_symbol, both of them
are return the first symbol that they found.
What about do some work on it?

What I think is:
In lookup_symbol and lookup_minimal_symbol, when it get a weak symbol,
just record it but keep search.  When the search complete, if GDB get
a simple symbol then return it.  If GDB doesn't get a simple symbol.
Then return the weak symbol.

BTW, looks minimal_symbol and symbol don't have interface access to
asymbol.  So I suggest we can extend "struct general_symbol_info" and
elf_symtab_read to make minimal_symbol and symbol have the weak
message.

Thanks,
Hui

Re: [RFC] make gdb handle weak function better

[Hui Zhu]

Ping.

On Thu, Aug 5, 2010 at 17:03, Hui Zhu <teawater@gmail.com> wrote:
> Hi,
>
> I meet following trouble:
> cat 1.c
> int
> main ()
> {
>        calloc (3, 1);
> }
> gcc -g 1.c
> gdb ./a.out
> (gdb) start
> Temporary breakpoint 1 at 0x8048385: file 1.c, line 4.
> Starting program: /home/teawater/gdb/bgdbno/gdb/a.out
>
> Temporary breakpoint 1, main () at 1.c:4
> 4               calloc (3, 1);
> (gdb) b calloc
> During symbol reading, incomplete CFI data; unspecified registers
> (e.g., eax) at 0x8048382.
> Breakpoint 2 at 0xb7ff82a6
> (gdb) info sharedlibrary
> From        To          Syms Read   Shared Object Library
> 0xb7fe47f0  0xb7ff97df  Yes (*)     /lib/ld-linux.so.2
> 0xb7e80230  0xb7f80ea4  Yes (*)     /lib/tls/i686/cmov/libc.so.6
> (*): Shared library is missing debugging information.
> (gdb) c
> Continuing.
>
> Program exited with code 010.
>
> The inferior is not break because gdb set breakpoint in the weak
> function calloc in lib/ld-linux.so.2.
> But the inferior call the calloc in /lib/tls/i686/cmov/libc.so.6.
>
> And I check the lookup_symbol and lookup_minimal_symbol, both of them
> are return the first symbol that they found.
> What about do some work on it?
>
> What I think is:
> In lookup_symbol and lookup_minimal_symbol, when it get a weak symbol,
> just record it but keep search.  When the search complete, if GDB get
> a simple symbol then return it.  If GDB doesn't get a simple symbol.
> Then return the weak symbol.
>
> BTW, looks minimal_symbol and symbol don't have interface access to
> asymbol.  So I suggest we can extend "struct general_symbol_info" and
> elf_symtab_read to make minimal_symbol and symbol have the weak
> message.
>
> Thanks,
> Hui
>

Re: [RFC] make gdb handle weak function better

[Chris January]

On Wed, 2010-08-11 at 11:21 +0800, Hui Zhu wrote:
> > (gdb) info sharedlibrary
> > From        To          Syms Read   Shared Object Library
> > 0xb7fe47f0  0xb7ff97df  Yes (*)     /lib/ld-linux.so.2
> > 0xb7e80230  0xb7f80ea4  Yes (*)     /lib/tls/i686/cmov/libc.so.6
> > (*): Shared library is missing debugging information.
> >
> > Program exited with code 010.
> >
> > The inferior is not break because gdb set breakpoint in the weak
> > function calloc in lib/ld-linux.so.2.
> > But the inferior call the calloc in /lib/tls/i686/cmov/libc.so.6.
> >
> > And I check the lookup_symbol and lookup_minimal_symbol, both of them
> > are return the first symbol that they found.
> > What about do some work on it?
> >
> > What I think is:
> > In lookup_symbol and lookup_minimal_symbol, when it get a weak symbol,
> > just record it but keep search.  When the search complete, if GDB get
> > a simple symbol then return it.  If GDB doesn't get a simple symbol.
> > Then return the weak symbol.

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.

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

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.

Regards,
Chris




This e-mail message may contain confidential and/or privileged information. If you are not an addressee or otherwise authorized to receive this message, you should not use, copy, disclose or take any action based on this e-mail or any information contained in the message.
If you have received this material in error, please advise the sender immediately by reply e-mail and delete this message. Thank you.
Allinea Software Limited: Registered in England and Wales No: 6871298
Registered Address: The Innovation Centre, Warwick Technology Park, Gallows Hill, Warwick, CV34 6UW, United Kingdom

Re: [RFC] make gdb handle weak function better

[Daniel Jacobowitz]

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

Re: [RFC] make gdb handle weak function better

[Hui Zhu]

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
>

Re: [RFC] make gdb handle weak function better

[Chris January]

On Wed, 2010-08-11 at 16:31 -0400, Daniel Jacobowitz wrote:
> 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.

Aside from breakpoints you still need to know which 'calloc' the dynamic
linker has bound in order to evaluate function calls, i.e.
print calloc(100)
ought to call the same 'calloc' as the inferior.

Regards,
Chris




This e-mail message may contain confidential and/or privileged information. If you are not an addressee or otherwise authorized to receive this message, you should not use, copy, disclose or take any action based on this e-mail or any information contained in the message.
If you have received this material in error, please advise the sender immediately by reply e-mail and delete this message. Thank you.
Allinea Software Limited: Registered in England and Wales No: 6871298
Registered Address: The Innovation Centre, Warwick Technology Park, Gallows Hill, Warwick, CV34 6UW, United Kingdom

Re: [RFC] make gdb handle weak function better

[Hui Zhu]

Now, GDB have support multi-address breakpoint.  I think maybe we can
do some work around it to fix it.

Thanks,
Hui

On Wed, Aug 18, 2010 at 16:17, Chris January <chris.january@allinea.com> wrote:
> On Wed, 2010-08-11 at 16:31 -0400, Daniel Jacobowitz wrote:
>> 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.
>
> Aside from breakpoints you still need to know which 'calloc' the dynamic
> linker has bound in order to evaluate function calls, i.e.
> print calloc(100)
> ought to call the same 'calloc' as the inferior.
>
> Regards,
> Chris
>
>
>
>
> This e-mail message may contain confidential and/or privileged information. If you are not an addressee or otherwise authorized to receive this message, you should not use, copy, disclose or take any action based on this e-mail or any information contained in the message.
> If you have received this material in error, please advise the sender immediately by reply e-mail and delete this message. Thank you.
> Allinea Software Limited: Registered in England and Wales No: 6871298
> Registered Address: The Innovation Centre, Warwick Technology Park, Gallows Hill, Warwick, CV34 6UW, United Kingdom
>