Re: Incorrect symbol name displayed in backtrace
William Tambe <[email protected]>
| Newsgroups | gmane.comp.gdb.devel |
|---|---|
| Message-ID | <CAF8i9mNZfiaEfdwyZyrtEuLFYO6h+Cfje63ddn29jFR4jFCi3w@mail.gmail.com> |
On Thu, Feb 6, 2020 at 10:32 PM Simon Marchi <[email protected]> wrote: > > On 2020-02-05 11:36 p.m., William Tambe wrote: > > Below is an example of backtrace where I find that GDB printed a > > symbol name that is not found at the address shown in the backtrace. > > In the example below, GDB says that __kprobes_text_start() is at > > 0x0039f000, however when I used p (void *)0x0039f000, it prints the > > correct symbol name at 0x0039f000. > > > > (gdb) bt > > #0 0x05000100 in _start () > > #1 0x0039f000 in __kprobes_text_start () > > Backtrace stopped: frame did not save the PC > > (gdb) p (void *)0x0039f000 > > $6 = (void *) 0x39f000 <__tramp_exit> > > > > > > Any idea what is the difference in the way symbol names are printed in > > the backtrace and by the command "p" ? > > The only reason I could imagine is that for the backtrace, GDB looks for > the closest code symbol, whereas with the print command, it looks for > any kind of symbol. And perhaps that in this case, __kprobes_text_start > is a code symbol whereas __tramp_exit is a data symbol. > > Note that when GDB says: > > #1 0x0039f000 in __kprobes_text_start () > > It doesn't mean that __kprobes_text_start == 0x0039f000, it's just that for > all it knows, the current address (0x0039f000) is in the function > __kprobes_text_start. What does "print __kprobes_text_start" say? (gdb) p __kprobes_text_start $22 = 0x39eda8 <__kprobes_text_start> "" __kprobes_text_start is not a function; it is declared as follow: extern char __kprobes_text_start[] > > It's hard to tell without seeing the actual binary, so this is just a guess. Is it possible to have pointers in the code where symbol names are printed for the backtrace and where they are printed for the command "p" ? > > Simon