can gdb step into static library ?

maxreason · 07-14-2012, 06:30 PM

When I am debugging my program that is linked to a shared library, I'm guessing gdb can't (or won't) let me step into code in the library, correct? If it did, it would risk other applications hitting the breakpoint it set, which would be a super-no-no.

However, is there any reason gdb can't (or won't) let me step into code in a static library linked into my program?

What would I need to make that happen? I'm debugging with codeblocks, and it doesn't let me step into functions being called.

dwhitney67 · 07-14-2012, 06:37 PM

Quote:

Originally Posted by maxreason

When I am debugging my program that is linked to a shared library, I'm guessing gdb can't (or won't) let me step into code in the library, correct? If it did, it would risk other applications hitting the breakpoint it set, which would be a super-no-no.

However, is there any reason gdb can't (or won't) let me step into code in a static library linked into my program?

What would I need to make that happen? I'm debugging with codeblocks, and it doesn't let me step into functions being called.

Both of your assumptions are incorrect. You can step into a shared-object library when debugging, and equally do the same with a static-library. The only caveat is that these libraries must be compiled with symbolic information; typically this is done by using the -g compiler option when compiling each source file.

maxreason · 07-14-2012, 08:55 PM

Quote:

Originally Posted by dwhitney67

Both of your assumptions are incorrect. You can step into a shared-object library when debugging, and equally do the same with a static-library. The only caveat is that these libraries must be compiled with symbolic information; typically this is done by using the -g compiler option when compiling each source file.

Why would it need symbols to single-step? I don't know how the library was compiled, but objdump displays all sorts of symbols, so that should be enough for gdb.

So I guess the question is, how can I make gdb step into the library?

NevemTeve · 07-14-2012, 11:21 PM

Use option -g at compilation and linkage.

knudfl · 07-15-2012, 03:09 AM

Quote:

but objdump displays all sorts of symbols, so that should be enough for gdb

'objdump' will show all objects (symbols ?).

It's the symbol information which is usually missing.

.

gchen · 07-15-2012, 07:43 AM

Firstly, -g means all symbols (source code level);

if no -g (and not strip), gcc will generate the symbols for none-inline functions and global variables (although, it is not source code level, but truly usful).

you can step into every shared library and static library with disassembly code (use m command, maybe it is, you can reference the gcc help command to know it).

if no -g (and not strip), you can see the relative none-inline function name and relative global variables. (you can use "disassemble" command, to disassemble the none-inline functions)

if have -g, you can see all things (with source code level).

if no -g and the binary executable are stripped, it is truly no symbols at all, but you still can step into the shared library and static library (but without symbols).

: )

maxreason · 07-15-2012, 04:16 PM

gchen: Thanks for the thorough information.

I guess this means that when I click "step-into" icon in codeblocks, they aren't executing the appropriate "step-into" in gdb (which is the adopted debugger).

And yes, as you say, the debugger clearly understands where assembly/machine-language instruction boundaries are (without symbols), otherwise it couldn't single step in assembly-language at all, which it does. And, of course, gdb couldn't execute the "disassemble" command, which it does.

My "off the cuff" guess was... shared libraries wouldn't work because they were configured as "read/execute-only" in memory (since other executables might be running the library, any breakpoint instructions stuck in the code would be a disaster). But I didn't see why static-linked would be any more protected than the original program, since they are all built into one executable.

I still don't have a definitive answer, but I'll go ask the guys at codeblocks what they do when someone tries to "step into" at a line that calls a function inside a static-linked library.

Thanks for the info about gdb.

gchen · 07-15-2012, 07:04 PM

Quote:

Originally Posted by maxreason

gchen: Thanks for the thorough information.

I guess this means that when I click "step-into" icon in codeblocks, they aren't executing the appropriate "step-into" in gdb (which is the adopted debugger).

And yes, as you say, the debugger clearly understands where assembly/machine-language instruction boundaries are (without symbols), otherwise it couldn't single step in assembly-language at all, which it does. And, of course, gdb couldn't execute the "disassemble" command, which it does.

My "off the cuff" guess was... shared libraries wouldn't work because they were configured as "read/execute-only" in memory (since other executables might be running the library, any breakpoint instructions stuck in the code would be a disaster). But I didn't see why static-linked would be any more protected than the original program, since they are all built into one executable.

I still don't have a definitive answer, but I'll go ask the guys at codeblocks what they do when someone tries to "step into" at a line that calls a function inside a static-linked library.

Thanks for the info about gdb.

1) The debugger will use "write copy" ways to solve the "read/execute-only" segements issue. So we can still step into shared library.

2) For shared memory (or filemap) (data segment, no read priority), the original gdb version can not access it (but maybe current gdb can do).

3) For GUI debugger, if no "-g", for step-into, default is failed (but after simply configured, it can step-into by showing disassembly code).

4) For different GUI debugger (or IDE), the configurations are different, but I am sure that they all include the features what I said above.

5) If you truly want see source code, commonly, you have to compile the shared library and static library with "-g" option (for Red Hat, it has another way to solve it).

I hope these information above might be usefull for you.

: )

bigearsbilly · 07-16-2012, 02:33 AM

you can use gdb standalone you know.