Stepping over library calls with gdb/gdbserver

9
votes

I have a general gdb/gdbserver question. I'm trying to debug an arm linux embedded application using gdb on the host and gdbserver on the remote target. I can step through lines of code at the beginning of main. However, gdb (or gdbserver) seems to get lost after calls to shared library functions. Even when I set a breakpoint after the call and use continue, it never hits the breakpoint. I know I don't have symbols in the shared libraries and really don't care to step into them. Shouldn't I be able to step over the library calls in gdb successfully even without the symbols being in the shared libraries or at least continue to the next breakpoint? Or does this indicate a different type of problem?

1
linuxgdbarmgdbserver
Do you have evidence from another source that indicates that it is executing the instruction(s) at the breakpoint? Instead of viewing the high level source, look at the disassembly to see past some of gdb's interpretation. – Brian Cain
Does the problem happen with one particular shared object, or can you create a trivial "test case" one which illustrates the problem? – Brian Cain
Sorry for the long response time. The code is running properly on the embedded device. It's just gdb or gdbserver that is getting lost. Once a call is made to a library function it loses track of its place in the program and can never regain control. I don't think it's necessarily all library function since it hits one, open(), that it can't get past early on in the execution. – Jim
Make sure you're not compiling with -fomit-frame-pointer and that you're not compiling with optimization (Force it to use -O0). Incidentally, there's really no reason why you shouldn't have symbols for the shared libraries on the remote box - you keep them on the machine you're running gdb on, and can add them in the case where you're debugging a stripped binary remotely - very useful. – synthesizerpatel

1 Answers

1
votes

Breakpoints by address, rather than by symbol, are sometimes more reliable.

Try this:

(gdb) x/i my_func
0x12345678 <my_func> ...
(gdb) break *0x12345678