Why are some debug symbols missing and how to track them? - c

Question

I am currently debugging a Kernel module and to this purpose, I built the whole kernel with debug information (produces kallsyms, etc ...).
When I try nm my_module.ko, I get the list of symbols included by my module. All is allright except that some symbols are kind of missing as they do not appear in the symbol list. My feeling about this is that the related functions are being automatically inlined.
Anyway, when running the kernel with qemu-kgdb/gdb, I am able to see that the "missing" function is called. This means the compiler did not wipe it out because it was never used in any code path (hence my "feeling").
Since the symbol does not appear, I can't set a breakpoint on it and gdb won't unroll it so that I can see the running code path - understand I don't know how to tell gdb to unroll it.
Unfortunately, I want to see this part of the code path ... How can I do so ?
EDIT : As suggested in Tom's answer, I tried using the file:line syntax as below :
My code file looks like this :
int foo(int arg) // The function that I suspect to be inlined - here is line 1
{
/* Blabla */
return 42;
}
void foo2(void)
{
foo(0); // Line 9
}
I tried b file.c:1, and the breakpoint was hit but the foo() function is not unrolled.
Of course, I am producing debug symbols, since I also set a breakpoint to foo2 to check what happened (which worked well).

Answer 1

You don't say what version of gdb you are using.
Very old versions of gdb don't have any support for inline functions. This was true for 6.8 and maybe even 7.0 -- I don't recall. You can look at the NEWS file for your gdb to see.
Then there were some versions of gdb that supported breakpoints on inline functions, but only using the "file:line" syntax. So what you would do is look up the function in your editor, and find its line number and enter, e.g.:
(gdb) break myfile.c:777
Even more recent versions of gdb, starting with 7.4 or 7.5 (I forget) will handle "break function" just fine if "function" was inlined.
All of this only works if you have debuginfo available. So if you tried this, and it failed, either you have an older gdb, or you forgot to use -g.
There's no good way inside gdb to see what objects in a compilation were missing -g. You can see it pretty easily from the shell, though, by running "readelf -WS" on the .o files, and looking for files that don't have a .debug_info section.

Answer 2

Setting a breakpoint to the signature line of the function did not work. But setting one to the line of an instruction of the inlined function solved the problem for me. For instance, considering the following function inline_foo, found in myfile.c:
inline int inline_foo(int arg) // l.1
{
int a_var = 0;
do_smth(&a_var);
do_some_other_thing(); // l.5
if (a_var) {
a_var = blob();
} else {
a_var = blub();
return a_var; // l.10
}
I was trying b myfile.c:1, which did not appear to work. But if I tried b myfile.c:3 instead, the breakpoint was well handled by GDB.
Since the technique is the same as the one described previously by Tom, I'll accept his answer.