Learn function name by its address

Learn function name by its address

[Dmitry Dzhus]

GDB's CLI command for examining memory provides helpful
`<function+offset>` annotations in its output:

    (gdb) x 0x80486cd
    0x80486cd <main+25>:	0x0000000a

MI `-data-read-memory` command yields only addresses:

    {addr="0x00001390",data=["0x00","0x01"]},
    {addr="0x00001392",data=["0x02","0x03"]}

What way of finding out function name by address would you suggest?
-- 
Happy Hacking.

http://sphinx.net.ru
ã‚€

Re: Learn function name by its address

[Paul Pluzhnikov]

On Thu, Jun 25, 2009 at 8:42 AM, Dmitry Dzhus<dima@sphinx.net.ru> wrote:

> What way of finding out function name by address would you suggest?

From "info gdb":

The `-symbol-info-symbol' Command
---------------------------------

Synopsis
........

      -symbol-info-symbol ADDR

   Describe what symbol is at location ADDR.


Cheers,
-- 
Paul Pluzhnikov

Re: Learn function name by its address

[Michael Snyder]

Paul Pluzhnikov wrote:
> On Thu, Jun 25, 2009 at 8:42 AM, Dmitry Dzhus<dima@sphinx.net.ru> wrote:
> 
>> What way of finding out function name by address would you suggest?
> 
> From "info gdb":
> 
> The `-symbol-info-symbol' Command
> ---------------------------------
> 
> Synopsis
> ........
> 
>       -symbol-info-symbol ADDR
> 
>    Describe what symbol is at location ADDR.

Or if you're using the CLI, just "info symbol ADDR".

Re: Learn function name by its address

[Dmitry Dzhus]

> -symbol-info-symbol

Oh, I missed that, thanks.

> what symbol is at location ADDR.

Is it correct that this information cannot change in runtime?
-- 
Happy Hacking.

http://sphinx.net.ru
む

Re: Learn function name by its address

[Paul Pluzhnikov]

On Thu, Jun 25, 2009 at 11:35 AM, Dmitry Dzhus<dima@sphinx.net.ru> wrote:

>> what symbol is at location ADDR.
> Is it correct that this information cannot change in runtime?

If the symbol is in a dynamically loaded shared library, and if that
library is unloaded and something else (including a new version of the
same library or some totally different one) is loaded in its place, then
the mapping of ADDR to symbol could well change at runtime.

Cheers,
-- 
Paul Pluzhnikov

Re: Learn function name by its address

[Nick Roberts]

Dmitry Dzhus writes:
 > > -symbol-info-symbol
 > 
 > Oh, I missed that, thanks.
 > 
 > > what symbol is at location ADDR.

-symbol-info-symbol
^error,msg="Undefined mi command: symbol-info-symbol (missing implementation)"
(gdb) 

This is one of many GDB/MI commands that are described in the manual but not
implemented, presumably because no-one has found a need for them.  Such
commands have:

  Example
  .......

  N.A.

after them in the manual.

For Emacs, I think that it is not necessary to give symbol information in
the memory contents buffer but just the addresses and values.  The user
should be able to specify a symbol as input, however, and the -data-read-memory
command allows that.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Learn function name by its address

[Dmitry Dzhus]

Nick Roberts wrote:

> -symbol-info-symbol
> ^error,msg="Undefined mi command: symbol-info-symbol (missing implementation)"
> (gdb) 
>
> This is one of many GDB/MI commands that are described in the manual but not
> implemented, presumably because no-one has found a need for them.  Such
> commands have:

Indeed.

> For Emacs, I think that it is not necessary to give symbol information in
> the memory contents buffer but just the addresses and values.

Seems like I'd have to issue dozens of `-symbol-info-symbol` commands to
get symbol information for addresses of the whole memory page shown in
memory buffer, one for each memory row, so it's hardly worth
implementing anyways due to possible overhead.

> The user should be able to specify a symbol as input

Sure, gdb-mi.el already has this.
-- 
Happy Hacking.

http://sphinx.net.ru
ã‚€

Re: Learn function name by its address

[André Pönitz]

On Thursday 25 June 2009 17:53:33 Paul Pluzhnikov wrote:
> On Thu, Jun 25, 2009 at 8:42 AM, Dmitry Dzhus<dima@sphinx.net.ru> wrote:
> 
> > What way of finding out function name by address would you suggest?
> 
> From "info gdb":
> 
> The `-symbol-info-symbol' Command
> ---------------------------------
> 
> Synopsis
> ........
> 
>       -symbol-info-symbol ADDR
> 
>    Describe what symbol is at location ADDR.

Looks like the wonders of MI's wishful thinking strike again:

apoenitz@gar:/tmp$ ~/gdb/fsf/src/gdb/gdb -i mi ./x
~"GNU gdb (GDB) 6.8.50.20090622-cvs\n"
~"Copyright (C) 2009 Free Software Foundation, Inc.\n"
~"License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>\n"
~"This is free software: you are free to change and redistribute it.\n"
~"There is NO WARRANTY, to the extent permitted by law.  Type \"show copying\"\n"
~"and \"show warranty\" for details.\n"
~"This GDB was configured as \"i686-pc-linux-gnu\".\n"
~"For bug reporting instructions, please see:\n"
~"<http://www.gnu.org/software/gdb/bugs/>...\n"
(gdb) 
b main
&"b main\n"
~"Breakpoint 1 at 0x805c72d: file x.cpp, line 475.\n"
^done
(gdb) 
-symbol-info-symbol 0x805c72d
^error,msg="Undefined mi command: symbol-info-symbol (missing implementation)"
(gdb) 

Same with  6.8.50.20090626-cvs. I don't have anything more recent.

Regards,
Andre'

Re: Learn function name by its address

[Paul Pluzhnikov]

On Thu, Jun 25, 2009 at 11:38 PM, André Pönitz<andre.poenitz@nokia.com> wrote:

> Looks like the wonders of MI's wishful thinking strike again:

> -symbol-info-symbol 0x805c72d
> ^error,msg="Undefined mi command: symbol-info-symbol (missing implementation)"

Indeed.

I am puzzled: what's the point of ducumenting un-implemented MI commands?
Looks like there is a whole lot of them :-(


-- 
Paul Pluzhnikov

Re: Learn function name by its address

[Tom Tromey]

>>>>> "Paul" == Paul Pluzhnikov <ppluzhnikov@google.com> writes:

Paul> I am puzzled: what's the point of ducumenting un-implemented MI commands?
Paul> Looks like there is a whole lot of them :-(

Yes, this seems very bad to me.  I think we also used to have some
unimplemented CLI commands as well... yuck.

If you have a list ready, would you mind writing a patch to remove
them from the documentation?

Tom

Re: Learn function name by its address

[Paul Pluzhnikov]

On Fri, Jun 26, 2009 at 10:26 AM, Tom Tromey<tromey@redhat.com> wrote:

> If you have a list ready, would you mind writing a patch to remove
> them from the documentation?

As Nick Roberts said earlier in the thread, these can be identified by

  Example ... N.A.

marker. I just didn't know what that meant.

I think removing them would be incorrect: they do exist, MI accepts them,
they just don't work :-(

Perhaps add a "NOTE: This command has not yet been implemented" to each one?

-- 
Paul Pluzhnikov

Re: Learn function name by its address

[Tom Tromey]

>>>>> "Paul" == Paul Pluzhnikov <ppluzhnikov@google.com> writes:

Paul> I think removing them would be incorrect: they do exist, MI accepts them,
Paul> they just don't work :-(

Ugh.  That seems even worse.

Paul> Perhaps add a "NOTE: This command has not yet been implemented"
Paul> to each one?

Or also nuke the non-working entries from the MI command table.
I can't think of a reason we'd want to have non-functional commands.
I'm sure we'd reject a new patch that added such a command.

Tom

Re: Learn function name by its address

[Michael Snyder]

Tom Tromey wrote:
>>>>>> "Paul" == Paul Pluzhnikov <ppluzhnikov@google.com> writes:
> 
> Paul> I think removing them would be incorrect: they do exist, MI accepts them,
> Paul> they just don't work :-(
> 
> Ugh.  That seems even worse.
> 
> Paul> Perhaps add a "NOTE: This command has not yet been implemented"
> Paul> to each one?
> 
> Or also nuke the non-working entries from the MI command table.
> I can't think of a reason we'd want to have non-functional commands.
> I'm sure we'd reject a new patch that added such a command.

What about just commenting them out, so that the work isn't lost
and someone may some day implement them?

Same for the docs -- can they be left in the source and just commented out?

Re: Learn function name by its address

[Paul Pluzhnikov]

On Fri, Jun 26, 2009 at 11:49 AM, Michael Snyder<msnyder@vmware.com> wrote:

> What about just commenting them out, so that the work isn't lost
> and someone may some day implement them?
>
> Same for the docs -- can they be left in the source and just commented out?

That sounds reasonable.
I'll send a patch in a bit :-)


-- 
Paul Pluzhnikov

Re: Learn function name by its address

[Tom Tromey]

>>>>> "Michael" == Michael Snyder <msnyder@vmware.com> writes:

Michael> What about just commenting them out, so that the work isn't
Michael> lost and someone may some day implement them?

Michael> Same for the docs -- can they be left in the source and just
Michael> commented out?

I tend to think that if nobody has implemented these in $X years, then
nobody ever will.  But then, I'm generally also in the "never comment
out code, just delete it" camp.

I don't think it is important enough to worry about though.  I would
approve either patch.

Tom

Re: Learn function name by its address

[Joel Brobecker]

> I tend to think that if nobody has implemented these in $X years, then
> nobody ever will.  But then, I'm generally also in the "never comment
> out code, just delete it" camp.

So am I. The code is still around, just in CVS instead of inside
a comment.  Leaving it commented out just creates more clutter that
tends to stay rather than being fixed. So I really favor deleting.

-- 
Joel

Re: Learn function name by its address

[Eli Zaretskii]

> Date: Fri, 26 Jun 2009 11:49:10 -0700
> From: Michael Snyder <msnyder@vmware.com>
> CC: Paul Pluzhnikov <ppluzhnikov@google.com>, =?ISO-8859-1?Q?Andr=E9_P=F6?=  =?ISO-8859-1?Q?nitz?= <andre.poenitz@nokia.com>,   "gdb@sourceware.org" <gdb@sourceware.org>
> 
> Same for the docs -- can they be left in the source and just commented out?

If someone wants to submit a patch that comments out unimplemented MI
commands, please use @ignore..@end ignore, and please make sure (by
looking at the code) that these commands are indeed unimplemented.
Please do NOT assume that any command which says "N.A." in Example is
necessarily unimplemented.

P.S. The reason that we have unimplemented commands in this part of
the manual is that it was produced from a white paper that described
the projected implementation of MI, when most of it was still on
paper.