public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* finding a function with address
@ 2001-02-01 12:43 Mathieu Dube
  2001-02-01 15:56 ` J.T. Conklin
  0 siblings, 1 reply; 8+ messages in thread
From: Mathieu Dube @ 2001-02-01 12:43 UTC (permalink / raw)
  To: gdb

Hi,
	Im debugging an application with gdb and when the app segfaults gdb
outputs :
0x400da0a4 in ?? ()

I would like to find out the name of the function that should be in the place
of the "??".

Can I know it and how?

						Thanks
						-Mat


-- 
Mathieu Dube					mathieu_dube@videotron.ca
Programmer					mat@mondo-live.com
Mondo-Live					www.flipr.com

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

* Re: finding a function with address
  2001-02-01 12:43 finding a function with address Mathieu Dube
@ 2001-02-01 15:56 ` J.T. Conklin
  2001-02-05  1:32   ` Eli Zaretskii
  0 siblings, 1 reply; 8+ messages in thread
From: J.T. Conklin @ 2001-02-01 15:56 UTC (permalink / raw)
  To: mathieu_dube; +Cc: gdb

>>>>> "Mathieu" == Mathieu Dube <mathieu_dube@videotron.ca> writes:
Mathieu> Im debugging an application with gdb and when the app
Mathieu> segfaults gdb outputs : 0x400da0a4 in ?? ()
Mathieu>
Mathieu> I would like to find out the name of the function that should
Mathieu> be in the place of the "??".

GDB should be able to determine the name of the function if it has a
symbol for that address.  If it doesn't, perhaps the PC has gone
outside your programs boundaries.  One common way this occurs is
when a function pointer is corrupted.

For example:
        $ cat foo.c
        int (*foo)() = 0x12345678;

        main()
        {
                foo();
        }
        $ gcc foo.c
        $ gdb a.out
        .
        .
        .
        (gdb) run
        Starting program: /tmp/a.out

        Program received signal SIGSEGV, Segmentation fault.
        0x12345678 in ?? ()
        (gdb) bt
        #0      0x12345678 in ?? ()
        #1      0x10ee in main ()


Perhaps you could share more information?  What is the target?  Is the
executable linked staticly or dynamically?  Is 0x400da0a4 within the
text segment of your executable.  Can you still get a backtrace (the
stack might not be corrupted)?

        --jtc

-- 
J.T. Conklin
RedBack Networks

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

* Re: finding a function with address
  2001-02-01 15:56 ` J.T. Conklin
@ 2001-02-05  1:32   ` Eli Zaretskii
  2001-02-05  9:21     ` Greg McGary
  0 siblings, 1 reply; 8+ messages in thread
From: Eli Zaretskii @ 2001-02-05  1:32 UTC (permalink / raw)
  To: J.T. Conklin; +Cc: gdb

On 1 Feb 2001, J.T. Conklin wrote:

> GDB should be able to determine the name of the function if it has a
> symbol for that address.

This reminds my one of my gripes with GDB.  Observe:

  C:\bin\gcc\gnu\emacs\src> gdb ../bin/emacs.exe
  GNU gdb 5.0
  Copyright 2000 Free Software Foundation, Inc.
  GDB is free software, covered by the GNU General Public License, and you are
  welcome to change it and/or distribute copies of it under certain conditions.
  Type "show copying" to see the conditions.
  There is absolutely no warranty for GDB.  Type "show warranty" for details.
  This GDB was configured as "i386-pc-msdosdjgpp"...
  (gdb) help info symbol
  Describe what symbol is at location ADDR.
  Only for symbols with fixed locations (global or static scope).
  (gdb) info address Qnil
  Symbol "Qnil" is static storage at address 0x1d6cd8.
  (gdb) info symbol 0x1d6cd8
  No symbol matches 0x1d6cd8.
  (gdb) info address command_loop
  Symbol "command_loop" is a function at address 0x4b940
  (gdb) info symbol 0x4b940
  No symbol matches 0x4b940.
  (gdb)

In other words, there doesn't seem to be a way of getting a symbol
name given its address, unlike "info symbol" promised?

Am I using GDB incorrectly?  Is this a bug in GDB or in its DJGPP
port?

Here's a relevant story from the trenches: I needed the help of `info
symbol' badly when I debugged a case of a crash due to stack overflow.
Since the stack was badly smashed, I couldn't even get a decent stack
trace, all I had was two top-most stack frames.  So my first goal was
to find out what was the sequence of function calls leading to the
stack overflow.  However, since some of the .data section was also
overwritten by the overflowing stack, I couldn't trust the program's
data structures.  So I decided to walk the stack manually, figuring
out the frames as I go.  This required to be able to find a function
given a return address pushed onto the stack when it called another
function.  Due to the above problems, I ended up using tricks like
`disassemble ADDRESS' and `list *ADDRESS'.  If I needed to do the same
for variables, I had to use `info address' in conjunction with
guessing and binary search...

As an aside, "info symbol" doesn't seem to be documented in the manual
(fix, fix).

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

* Re: finding a function with address
  2001-02-05  1:32   ` Eli Zaretskii
@ 2001-02-05  9:21     ` Greg McGary
  2001-02-06  8:37       ` Eli Zaretskii
  0 siblings, 1 reply; 8+ messages in thread
From: Greg McGary @ 2001-02-05  9:21 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: J.T. Conklin, gdb

Eli Zaretskii <eliz@is.elta.co.il> writes:

> In other words, there doesn't seem to be a way of getting a symbol
> name given its address, unlike "info symbol" promised?

I always get symbol names like so:

(gdb) p/a 0x4b940

However, if the `info symbol ADDR' doesn't work, then this might not
work either.

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

* Re: finding a function with address
  2001-02-05  9:21     ` Greg McGary
@ 2001-02-06  8:37       ` Eli Zaretskii
  0 siblings, 0 replies; 8+ messages in thread
From: Eli Zaretskii @ 2001-02-06  8:37 UTC (permalink / raw)
  To: greg; +Cc: jtc, gdb

> From: Greg McGary <greg@mcgary.org>
> Date: 05 Feb 2001 10:20:58 -0700
> 
> Eli Zaretskii <eliz@is.elta.co.il> writes:
> 
> > In other words, there doesn't seem to be a way of getting a symbol
> > name given its address, unlike "info symbol" promised?
> 
> I always get symbol names like so:
> 
> (gdb) p/a 0x4b940
> 
> However, if the `info symbol ADDR' doesn't work, then this might not
> work either.

Thanks for the tip.  Amazingly enough, "p/a" does work.

It's probably a bug.  I will debug it.

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

* Re: finding a function with address
  2001-02-05  5:29 Michael Elizabeth Chastain
       [not found] ` <200102051025.LAA26655@reisser.regent.e-technik.tu-muenchen.de>
@ 2001-02-06 13:09 ` Eli Zaretskii
  1 sibling, 0 replies; 8+ messages in thread
From: Eli Zaretskii @ 2001-02-06 13:09 UTC (permalink / raw)
  To: chastain; +Cc: jtc, gdb

> From: Michael Elizabeth Chastain <chastain@cygnus.com>
> Date: Mon, 5 Feb 2001 05:29:00 -0800
> 
> My enhancement request: "info sections".  It would have an
> ALL_OBJSECTIONS loop and a lot of printf_filtered calls.

What would you like it to print for each section?

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

* Re: finding a function with address
       [not found] ` <200102051025.LAA26655@reisser.regent.e-technik.tu-muenchen.de>
@ 2001-02-06 10:01   ` Eli Zaretskii
  0 siblings, 0 replies; 8+ messages in thread
From: Eli Zaretskii @ 2001-02-06 10:01 UTC (permalink / raw)
  To: Michael Elizabeth Chastain, Peter.Schauer; +Cc: jtc, gdb

> From: Michael Elizabeth Chastain <chastain@cygnus.com>
> Date: Mon, 5 Feb 2001 05:29:00 -0800
> 
> Eli Zaretskii writes:
> 
> > Am I using GDB incorrectly?  Is this a bug in GDB or in its DJGPP
> > port?
> 
> "info symbols" appears to work for me (sourceware gdb, Red Hat Linux 7).

Let me guess: you both use systems where the debug info is ELF (or
maybe DWARF2), right?

I debugged this, and the reason for the different behavior between
"print/a" and "info symbol" is that the latter calls
`lookup_minimal_symbol_by_pc_section' with a non-NULL argument
SECTION; "print/a" passes NULL there.  If SECTION is non-NULL,
`lookup_minimal_symbol_by_pc_section' rejects symbol table entries
whose SYMBOL_BFD_SECTION is not equal to the passed SECTION.

Here's the scoop: many debug formats, including COFF, put NULL into
SYMBOL_BFD_SECTION, see `prim_record_minimal_symbol' and all its
callers.  This makes `lookup_minimal_symbol_by_pc_section' reject all
symbols it finds, and come up empty handed.

Can someone who knows his/her way inside minsyms.c please suggest how
to fix this?  It seems that in its current shape,
`lookup_minimal_symbol_by_pc_section' is too harsh to quite a few
platforms, so I think we'd better change that.  Would an additional
test for SYMBOL_BFD_SECTION being non-NULL be okay, for example?

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

* Re: finding a function with address
@ 2001-02-05  5:29 Michael Elizabeth Chastain
       [not found] ` <200102051025.LAA26655@reisser.regent.e-technik.tu-muenchen.de>
  2001-02-06 13:09 ` Eli Zaretskii
  0 siblings, 2 replies; 8+ messages in thread
From: Michael Elizabeth Chastain @ 2001-02-05  5:29 UTC (permalink / raw)
  To: eliz, jtc; +Cc: gdb

Eli Zaretskii writes:

> Am I using GDB incorrectly?  Is this a bug in GDB or in its DJGPP
> port?

"info symbols" appears to work for me (sourceware gdb, Red Hat Linux 7).

My enhancement request: "info sections".  It would have an
ALL_OBJSECTIONS loop and a lot of printf_filtered calls.

Michael Elizabeth Chastain
<chastain@redhat.com>
"love without fear"

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

end of thread, other threads:[~2001-02-06 13:09 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-02-01 12:43 finding a function with address Mathieu Dube
2001-02-01 15:56 ` J.T. Conklin
2001-02-05  1:32   ` Eli Zaretskii
2001-02-05  9:21     ` Greg McGary
2001-02-06  8:37       ` Eli Zaretskii
2001-02-05  5:29 Michael Elizabeth Chastain
     [not found] ` <200102051025.LAA26655@reisser.regent.e-technik.tu-muenchen.de>
2001-02-06 10:01   ` Eli Zaretskii
2001-02-06 13:09 ` Eli Zaretskii

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).