* 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