Mirror of the gdb mailing list
 help / color / mirror / Atom feed
* Display libc function names instead of address ?
@ 2005-06-16  3:36 Victor STINNER
  2005-06-16  4:43 ` Daniel Jacobowitz
  2005-06-16 18:21 ` Eli Zaretskii
  0 siblings, 2 replies; 13+ messages in thread
From: Victor STINNER @ 2005-06-16  3:36 UTC (permalink / raw)
  To: gdb

Hi,

I woud like to know if it is possible to display libc functions name
instead of their address. Example :

(1) (...) // prepare parameters
    call 0x8048728

(2) jmp *0x804a6b0 // in relocation table, at 0x08048728

And if I do a "objdump -R file | grep 0x804a6b0", it answers printf. So
is it possible to display "call printf" instead of "call 0x8048728" ? Or
at least display "jmp *<printf>" instead of "jmp *0x804a6b0" ?

I think that gdb can already read relocation table because "print
printf" command give me the function address.

I hope that it's just an option :-)

Bye, Haypo


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Display libc function names instead of address ?
  2005-06-16  3:36 Display libc function names instead of address ? Victor STINNER
@ 2005-06-16  4:43 ` Daniel Jacobowitz
  2005-06-16 15:04   ` Victor STINNER
  2005-06-16 18:21 ` Eli Zaretskii
  1 sibling, 1 reply; 13+ messages in thread
From: Daniel Jacobowitz @ 2005-06-16  4:43 UTC (permalink / raw)
  To: Victor STINNER; +Cc: gdb

On Thu, Jun 16, 2005 at 05:36:00AM +0200, Victor STINNER wrote:
> Hi,
> 
> I woud like to know if it is possible to display libc functions name
> instead of their address. Example :
> 
> (1) (...) // prepare parameters
>     call 0x8048728
> 
> (2) jmp *0x804a6b0 // in relocation table, at 0x08048728
> 
> And if I do a "objdump -R file | grep 0x804a6b0", it answers printf. So
> is it possible to display "call printf" instead of "call 0x8048728" ? Or
> at least display "jmp *<printf>" instead of "jmp *0x804a6b0" ?
> 
> I think that gdb can already read relocation table because "print
> printf" command give me the function address.
> 
> I hope that it's just an option :-)

GDB can't do this - but, I think, that the very latest BFD/opcodes
library supports this for some targets.  Someone needs to hook those
bits up to GDB.

-- 
Daniel Jacobowitz
CodeSourcery, LLC


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Display libc function names instead of address ?
  2005-06-16  4:43 ` Daniel Jacobowitz
@ 2005-06-16 15:04   ` Victor STINNER
  2005-06-16 15:20     ` Daniel Jacobowitz
  0 siblings, 1 reply; 13+ messages in thread
From: Victor STINNER @ 2005-06-16 15:04 UTC (permalink / raw)
  To: gdb

Le jeudi 16 juin 2005 à 00:43 -0400, Daniel Jacobowitz a écrit :
> GDB can't do this - but, I think, that the very latest BFD/opcodes
> library supports this for some targets.  Someone needs to hook those
> bits up to GDB.

Yep you're right. Google said me that BFD and opcodes are part of
binutils. So I took last CVS version. It gives me better result :

 804839b:       e8 10 ff ff ff          call   80482b0 <printf@plt>
instead of
 804839b:       e8 10 ff ff ff          call   80482b0 <_init+0x38>

So I think that I have to wait until next GDB release.

Bye, Haypo


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Display libc function names instead of address ?
  2005-06-16 15:04   ` Victor STINNER
@ 2005-06-16 15:20     ` Daniel Jacobowitz
  2005-06-16 15:46       ` Victor STINNER
  0 siblings, 1 reply; 13+ messages in thread
From: Daniel Jacobowitz @ 2005-06-16 15:20 UTC (permalink / raw)
  To: Victor STINNER; +Cc: gdb

On Thu, Jun 16, 2005 at 05:00:45PM +0200, Victor STINNER wrote:
> Le jeudi 16 juin 2005 à 00:43 -0400, Daniel Jacobowitz a écrit :
> > GDB can't do this - but, I think, that the very latest BFD/opcodes
> > library supports this for some targets.  Someone needs to hook those
> > bits up to GDB.
> 
> Yep you're right. Google said me that BFD and opcodes are part of
> binutils. So I took last CVS version. It gives me better result :
> 
>  804839b:       e8 10 ff ff ff          call   80482b0 <printf@plt>
> instead of
>  804839b:       e8 10 ff ff ff          call   80482b0 <_init+0x38>
> 
> So I think that I have to wait until next GDB release.

Thanks for checking!  That's output from objdump, right?  It doesn't
seem to work for me in GDB, just in objdump.  But perhaps I can figure
out where to wire it in.

-- 
Daniel Jacobowitz
CodeSourcery, LLC


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Display libc function names instead of address ?
  2005-06-16 15:20     ` Daniel Jacobowitz
@ 2005-06-16 15:46       ` Victor STINNER
  0 siblings, 0 replies; 13+ messages in thread
From: Victor STINNER @ 2005-06-16 15:46 UTC (permalink / raw)
  To: gdb

Le jeudi 16 juin 2005 à 11:19 -0400, Daniel Jacobowitz a écrit :
> Thanks for checking!  That's output from objdump, right?  It doesn't
> seem to work for me in GDB, just in objdump.  But perhaps I can figure
> out where to wire it in.

Yep, it's in objdump. I think that you just have to update bfd and
opcodes libraries, no ?

Bye, Haypo


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Display libc function names instead of address ?
  2005-06-16  3:36 Display libc function names instead of address ? Victor STINNER
  2005-06-16  4:43 ` Daniel Jacobowitz
@ 2005-06-16 18:21 ` Eli Zaretskii
  2005-06-16 18:29   ` Daniel Jacobowitz
  1 sibling, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2005-06-16 18:21 UTC (permalink / raw)
  To: victor.stinner; +Cc: gdb

> Date: Thu, 16 Jun 2005 05:36:00 +0200
> From: Victor STINNER <victor.stinner@haypocalc.com>
> 
> I woud like to know if it is possible to display libc functions name
> instead of their address. Example :
> 
> (1) (...) // prepare parameters
>     call 0x8048728
> 
> (2) jmp *0x804a6b0 // in relocation table, at 0x08048728

In response of what command(s) would you like to see the function
names?  Can you post an example of a command and its current output?


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Display libc function names instead of address ?
  2005-06-16 18:21 ` Eli Zaretskii
@ 2005-06-16 18:29   ` Daniel Jacobowitz
  2005-06-16 18:56     ` Eli Zaretskii
  0 siblings, 1 reply; 13+ messages in thread
From: Daniel Jacobowitz @ 2005-06-16 18:29 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: victor.stinner, gdb

On Thu, Jun 16, 2005 at 09:21:09PM +0200, Eli Zaretskii wrote:
> > Date: Thu, 16 Jun 2005 05:36:00 +0200
> > From: Victor STINNER <victor.stinner@haypocalc.com>
> > 
> > I woud like to know if it is possible to display libc functions name
> > instead of their address. Example :
> > 
> > (1) (...) // prepare parameters
> >     call 0x8048728
> > 
> > (2) jmp *0x804a6b0 // in relocation table, at 0x08048728
> 
> In response of what command(s) would you like to see the function
> names?  Can you post an example of a command and its current output?

Here's an example of the effect of the patch I just posted to
gdb-patches.  With an unpatched GDB, load gdb on a Linux system and run
"disas captured_main":

0x0807c0ac <captured_main+76>:  mov    %eax,0x4(%esp)
0x0807c0b0 <captured_main+80>:  movl   $0x5,(%esp)
0x0807c0b7 <captured_main+87>:  call   0x807b3a0 <_init+952>
0x0807c0bc <captured_main+92>:  movl   $0x0,(%esp)
0x0807c0c3 <captured_main+99>:  mov    $0x8239443,%eax
0x0807c0c8 <captured_main+104>: mov    %eax,0x4(%esp)
0x0807c0cc <captured_main+108>: call   0x807b3a0 <_init+952>

With the patch applied:

0x0807c0ac <captured_main+76>:  mov    %eax,0x4(%esp)
0x0807c0b0 <captured_main+80>:  movl   $0x5,(%esp)
0x0807c0b7 <captured_main+87>:  call   0x807b3a0 <setlocale@plt>
0x0807c0bc <captured_main+92>:  movl   $0x0,(%esp)
0x0807c0c3 <captured_main+99>:  mov    $0x8239443,%eax
0x0807c0c8 <captured_main+104>: mov    %eax,0x4(%esp)
0x0807c0cc <captured_main+108>: call   0x807b3a0 <setlocale@plt>

This doesn't work absolutely everywhere, of course.  It requires
target-specific support inside BFD.

-- 
Daniel Jacobowitz
CodeSourcery, LLC


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Display libc function names instead of address ?
  2005-06-16 18:29   ` Daniel Jacobowitz
@ 2005-06-16 18:56     ` Eli Zaretskii
  2005-06-16 19:03       ` Daniel Jacobowitz
  0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2005-06-16 18:56 UTC (permalink / raw)
  To: victor.stinner, gdb

> Date: Thu, 16 Jun 2005 14:29:36 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: victor.stinner@haypocalc.com, gdb@sources.redhat.com
> 
> Here's an example of the effect of the patch I just posted to
> gdb-patches.  With an unpatched GDB, load gdb on a Linux system and run
> "disas captured_main":
> 
> 0x0807c0ac <captured_main+76>:  mov    %eax,0x4(%esp)
> 0x0807c0b0 <captured_main+80>:  movl   $0x5,(%esp)
> 0x0807c0b7 <captured_main+87>:  call   0x807b3a0 <_init+952>
> 0x0807c0bc <captured_main+92>:  movl   $0x0,(%esp)
> 0x0807c0c3 <captured_main+99>:  mov    $0x8239443,%eax
> 0x0807c0c8 <captured_main+104>: mov    %eax,0x4(%esp)
> 0x0807c0cc <captured_main+108>: call   0x807b3a0 <_init+952>
> 
> With the patch applied:
> 
> 0x0807c0ac <captured_main+76>:  mov    %eax,0x4(%esp)
> 0x0807c0b0 <captured_main+80>:  movl   $0x5,(%esp)
> 0x0807c0b7 <captured_main+87>:  call   0x807b3a0 <setlocale@plt>
> 0x0807c0bc <captured_main+92>:  movl   $0x0,(%esp)
> 0x0807c0c3 <captured_main+99>:  mov    $0x8239443,%eax
> 0x0807c0c8 <captured_main+104>: mov    %eax,0x4(%esp)
> 0x0807c0cc <captured_main+108>: call   0x807b3a0 <setlocale@plt>

I don't understand: what is this "setlocale@plt" thingy?

Anyway, I tried this with GDB 6.1 on a Debian box and saw this:

    0x0807a8ab <captured_main+75>:  mov    %eax,0xffffff10(%ebp)
    0x0807a8b1 <captured_main+81>:  add    $0xfffffff8,%esp
    0x0807a8b4 <captured_main+84>:  push   $0x81ca040
    0x0807a8b9 <captured_main+89>:  push   $0x5
    0x0807a8bb <captured_main+91>:  call   0x8079bec <setlocale>
    0x0807a8c0 <captured_main+96>:  add    $0xfffffff8,%esp
    0x0807a8c3 <captured_main+99>:  push   $0x81ca040
    0x0807a8c8 <captured_main+104>: push   $0x0
    0x0807a8ca <captured_main+106>: call   0x8079bec <setlocale>
    0x0807a8cf <captured_main+111>: add    $0x20,%esp
    0x0807a8d2 <captured_main+114>: add    $0xfffffff8,%esp
    0x0807a8d5 <captured_main+117>: push   $0x81ca041

which seems to show the names of library functions just fine.

I then tried this with GDB 6.3 and a MinGW build of Emacs on a
Windows XP box and saw things like this:

    0x0100216d <main+341>:  movl   $0x1,0xffffffd4(%ebp)
    0x01002174 <main+348>:  movl   $0x128a50f,0x4(%esp)
    0x0100217c <main+356>:  movl   $0x0,(%esp)
    0x01002183 <main+363>:  call   0x114f7e0 <setlocale>
    ...
    0x010021e1 <main+457>:  movl   $0x0,(%esp)
    0x010021e8 <main+464>:  call   0x114f7c0 <_isatty>
    ...
    0x010021f5 <main+477>:  mov    0xffffffe4(%ebp),%eax
    0x010021f8 <main+480>:  movl   $0x128a646,0x4(%esp)
    0x01002200 <main+488>:  mov    %eax,0x8(%esp)
    0x01002204 <main+492>:  mov    0x12fab38,%eax
    0x01002209 <main+497>:  add    $0x40,%eax
    0x0100220c <main+500>:  mov    %eax,(%esp)
    0x0100220f <main+503>:  call   0x114f830 <fprintf>

which again shows library functions with their full name.

So I'm unsure what is the problem.  Am I missing something?


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Display libc function names instead of address ?
  2005-06-16 18:56     ` Eli Zaretskii
@ 2005-06-16 19:03       ` Daniel Jacobowitz
  2005-06-17  9:44         ` Eli Zaretskii
  0 siblings, 1 reply; 13+ messages in thread
From: Daniel Jacobowitz @ 2005-06-16 19:03 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: victor.stinner, gdb

On Thu, Jun 16, 2005 at 09:56:11PM +0200, Eli Zaretskii wrote:
> > 0x0807c0ac <captured_main+76>:  mov    %eax,0x4(%esp)
> > 0x0807c0b0 <captured_main+80>:  movl   $0x5,(%esp)
> > 0x0807c0b7 <captured_main+87>:  call   0x807b3a0 <setlocale@plt>
> > 0x0807c0bc <captured_main+92>:  movl   $0x0,(%esp)
> > 0x0807c0c3 <captured_main+99>:  mov    $0x8239443,%eax
> > 0x0807c0c8 <captured_main+104>: mov    %eax,0x4(%esp)
> > 0x0807c0cc <captured_main+108>: call   0x807b3a0 <setlocale@plt>
> 
> I don't understand: what is this "setlocale@plt" thingy?

It's a "synthetic" symbol.  It's not really in the symbol table; but
BFD provides it as an informative marker.  It means that the call
instruction will go to a PLT entry for setlocale.

> Anyway, I tried this with GDB 6.1 on a Debian box and saw this:
> 
>     0x0807a8bb <captured_main+91>:  call   0x8079bec <setlocale>
> 
> which seems to show the names of library functions just fine.

I haven't worked with Debian/woody in a bit, so I'd forgotten about
this.  If you try it on the new Debian stable release, you'll see the
calls to _init.  They're the result of a performance improvement in
binutils.

[I can go into more detail if you're curious.  They would sometimes
show up on the older binutils, but I can not remember the
circumstances.]

> I then tried this with GDB 6.3 and a MinGW build of Emacs on a
> Windows XP box and saw things like this:
> 
>     0x0100216d <main+341>:  movl   $0x1,0xffffffd4(%ebp)
>     0x01002174 <main+348>:  movl   $0x128a50f,0x4(%esp)
>     0x0100217c <main+356>:  movl   $0x0,(%esp)
>     0x01002183 <main+363>:  call   0x114f7e0 <setlocale>

Yes, Windows is not affected by this problem - it's related to shared
libraries and dynamic linking, and Windows DLL linking is different
enough that it does not have this quirk - though I'm sure it has plenty
of its own.

-- 
Daniel Jacobowitz
CodeSourcery, LLC


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Display libc function names instead of address ?
  2005-06-16 19:03       ` Daniel Jacobowitz
@ 2005-06-17  9:44         ` Eli Zaretskii
  2005-06-17 11:44           ` Victor STINNER
                             ` (2 more replies)
  0 siblings, 3 replies; 13+ messages in thread
From: Eli Zaretskii @ 2005-06-17  9:44 UTC (permalink / raw)
  To: gdb

> Date: Thu, 16 Jun 2005 15:03:15 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: victor.stinner@haypocalc.com, gdb@sources.redhat.com
> 
> Yes, Windows is not affected by this problem - it's related to shared
> libraries and dynamic linking, and Windows DLL linking is different
> enough that it does not have this quirk - though I'm sure it has plenty
> of its own.

Ah, the lights go on: so this problem only happens with dynamically
linked programs?  If so, that is what I was missing.  Thanks for
explaining it.


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Display libc function names instead of address ?
  2005-06-17  9:44         ` Eli Zaretskii
@ 2005-06-17 11:44           ` Victor STINNER
  2005-06-17 13:56           ` Daniel Jacobowitz
  2005-06-18 13:12           ` Eli Zaretskii
  2 siblings, 0 replies; 13+ messages in thread
From: Victor STINNER @ 2005-06-17 11:44 UTC (permalink / raw)
  To: gdb

> Ah, the lights go on: so this problem only happens with dynamically
> linked programs?  If so, that is what I was missing.  Thanks for
> explaining it.

Yes, I was speaking about dynamically linked programs. That's why I was
speaking about "objdump -R", dynamical relocation.

Bye, Haypo
PS: I subscribed to GDB mailing-list since my first post.


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Display libc function names instead of address ?
  2005-06-17  9:44         ` Eli Zaretskii
  2005-06-17 11:44           ` Victor STINNER
@ 2005-06-17 13:56           ` Daniel Jacobowitz
  2005-06-18 13:12           ` Eli Zaretskii
  2 siblings, 0 replies; 13+ messages in thread
From: Daniel Jacobowitz @ 2005-06-17 13:56 UTC (permalink / raw)
  To: gdb

On Fri, Jun 17, 2005 at 12:44:21PM +0200, Eli Zaretskii wrote:
> > Date: Thu, 16 Jun 2005 15:03:15 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: victor.stinner@haypocalc.com, gdb@sources.redhat.com
> > 
> > Yes, Windows is not affected by this problem - it's related to shared
> > libraries and dynamic linking, and Windows DLL linking is different
> > enough that it does not have this quirk - though I'm sure it has plenty
> > of its own.
> 
> Ah, the lights go on: so this problem only happens with dynamically
> linked programs?  If so, that is what I was missing.  Thanks for
> explaining it.

Right!  Sorry that wasn't clear.  The patch actually affects things
other than dynamic linking - but not for most platforms.  It fills in
symbols at places where there are no symbols in the ELF object, but
symbols would be useful to have, and there's a logical symbol to put
there.  Another example is PowerPC64 "dot" symbols, which label
function descriptors.

-- 
Daniel Jacobowitz
CodeSourcery, LLC


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Display libc function names instead of address ?
  2005-06-17  9:44         ` Eli Zaretskii
  2005-06-17 11:44           ` Victor STINNER
  2005-06-17 13:56           ` Daniel Jacobowitz
@ 2005-06-18 13:12           ` Eli Zaretskii
  2 siblings, 0 replies; 13+ messages in thread
From: Eli Zaretskii @ 2005-06-18 13:12 UTC (permalink / raw)
  To: gdb

> Date: Fri, 17 Jun 2005 12:44:21 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > Date: Thu, 16 Jun 2005 15:03:15 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: victor.stinner@haypocalc.com, gdb@sources.redhat.com
> > 
> > Yes, Windows is not affected by this problem - it's related to shared
> > libraries and dynamic linking, and Windows DLL linking is different
> > enough that it does not have this quirk - though I'm sure it has plenty
> > of its own.
> 
> Ah, the lights go on: so this problem only happens with dynamically
> linked programs?  If so, that is what I was missing.  Thanks for
> explaining it.

I wrote up something in the manual about this.


^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2005-06-18 13:12 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-06-16  3:36 Display libc function names instead of address ? Victor STINNER
2005-06-16  4:43 ` Daniel Jacobowitz
2005-06-16 15:04   ` Victor STINNER
2005-06-16 15:20     ` Daniel Jacobowitz
2005-06-16 15:46       ` Victor STINNER
2005-06-16 18:21 ` Eli Zaretskii
2005-06-16 18:29   ` Daniel Jacobowitz
2005-06-16 18:56     ` Eli Zaretskii
2005-06-16 19:03       ` Daniel Jacobowitz
2005-06-17  9:44         ` Eli Zaretskii
2005-06-17 11:44           ` Victor STINNER
2005-06-17 13:56           ` Daniel Jacobowitz
2005-06-18 13:12           ` Eli Zaretskii

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox