Hi,

I am using gdbserver in the remote device.
>./gdbserver 127.0.0.1:20000 ./a.out
Process ./a.out created; pid = 15379
Listening on port 20000


Started GDB on the host
>gdb ./a.out
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
(gdb) target remote IP:20000
Remote debugging using IP:20000
[New Thread 15379]
0x00000000 in ?? ()


I am getting ?? instead of the function name or symbols. Even if I try to print the stack trace, it prints ?? for all function names.

(Symbols are not stripped out in a.out executable)

Please let me know how to enable the function-names or a way to map the printed function address with the function name.


Thanks,
Jai

There is a difference between stripping the normal symbols from the executable and not putting in extra debugging symbols in the first place.

For a normal compile, gcc will optimize away a lot of symbols because they are self-contained and not needed by external objects. In order for gcc to emit the debugging symbols, you should compile using the “-g” flag. Moreover, you may want any libraries used by your program also to have debugging symbols included (typically your distribution may keep special “debug” versions of all its libraries available).

Hi,

I tried the -g option as well. But it gives the same result.
I am getting ?? in place of function names.

The function addresses "0x00000001" and "0x00000000" are incorrect and not mapping in the symbol table.

Please let me know how to get correct addresses from gdbserver, so that gdb can lookup correctly.

Thanks,
Jai

I seemed to have hastily read your initial post. If you are getting 0x00000001 and such as function addresses, you most likely have stack corruption. In that case, you have to find out what’s happening before you get to the offending code (once the stack has been corrupted, stack unwinding/bactracing will not work). Another possibility is that you compiled with -fomit-frame-pointer (but this seems unlikely).

By the way (if you have a fairly recent gcc), you might want to compile with a stack_guard (by using the flag -fstack-protector-all). This could point out the offending function before the stack corruption, on which you could then set a breakpoint in gdb.