3 ms·

Related question for the GDB experts: My day-job involves GDBing C code. I use a handful of functions regularly when I'm trying to pin down a bug, mostly just

Related question for the GDB experts: My day-job involves GDBing C code. I use a handful of functions regularly when I'm trying to pin down a bug, mostly just to double-check why the code is following a given branch. So I'm heavily dependent on memcmp, strncmp, etc. I've noticed that those functions fail if I start trying to use them too early, so I end up having to add a "b main" first and wait until I get to the breakpoint before they become available. Can someone explain why? I assume it has to do with getting far enough along in the program's execution that the shared libs have been loaded into memory?

aknoob 9y ago
Your assumption is right. Once the shared library gets loaded in the process address space. You can also set a breakpoint on module load.
DannyBee 9y ago
When you say fail, what happens? If you mean you can't call them, yes, it's shared libs, they aren't in the address space yet. If you mean something else (IE the symbol info is wrong), you can debug what is going on as follows: The logic for when it builds minimal symbol tables, converting them to partial symbol tables, and then full symbol tables, is incredibly convoluted. In theory, needing a full symbol with type info should just cause the right thing to happen lazily. In practice, it does not. You can debug what is going on by doing this: (gdb) set debug symbol-lookup 1 (gdb) set debug symtab-create 1 (gdb) file <your executable> (gdb) p strcmp("foo", "bar") <look at output> (gdb) b main (gdb) p strcmp <look at output> This is going to produce a truly ridiculous amount of output on a large executable (so i'd use a minimal one :P), but by comparing the output you get trying to use the symbol before and after "b main" should give you some idea what is going on.