* 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