Can GDB parse global data from xx.so without executable? - debugging

Question

I have a shared library (hlapi.so) running on linux system. This hlapi.so has many modules(I mean .c files ). One of them is named as hlapi.c which defines two global datas like this:
static int hlapiInitialized = FALSE;
static struct hlapi_data app_sp;
Of course there are many other codes in this hlapi.c module. The hlapi.so is released to customer who builds their own application (named as appbasehlapi) based on our hlapi.so.
Now I got a core dump whose backtrace parsed by customer shows the core is in our codes. But the customer can only provide us the core dump file. The appbasehlapi executable will not be shared with us. So in my hands, I have only the core dump file + hlapi.so.
In order to debug this core, I load the core dump file by command
gdb --core=mycoredumpfile
and then in gdb, I use
set solib-search-path .
to specify the folder which contains hlapi.so so that gdb can load symbols from hlapi.so. And then I use:
print hlapiInitialized
print app_sp
to parse the global data in our module. But the output values are very abnormal.
My question here is that if I can parse global datas defined in the hlapi.so via gdb without the executable? If the outputs I got via gdb are believable?
I am appreciating any comment.
BTW, the hlapi.so is built with gcc options "-g -fPIC".

Answer 1

I investigated the questions for a while, and in my opinion, I believe GDB can parse the global variables without the executable.
In the test, the following codes are in hlapi.cpp:
static int hlapiInitialized = 0;
void hlapiInit()
{
if (hlapiInitialized == 0)
{
// do something else
}
hlapiInitialized = 1;
}
The objdump shows the assembly codes for it is:
00000000000009a2 <_Z9hlapiInitv>:
9a2: 55 push %rbp
9a3: 48 89 e5 mov %rsp,%rbp
9a6: c7 05 98 06 20 00 01 movl $0x1,0x200698(%rip) # 201048 <_ZL16hlapiInitialized>
9ad: 00 00 00
9b0: 90 nop
9b1: 5d pop %rbp
9b2: c3 retq
During running the application, I generate a core dump against it. In gdb, before specifying the solib-search-path, I get:
(gdb) disas hlapiInit
No symbol table is loaded. Use the "file" command.
Once the search path is specified, the output is:
(gdb) disas hlapiInit
Dump of assembler code for function hlapiInit():
0x00007ffff7bd59a2 <+0>: push %rbp
0x00007ffff7bd59a3 <+1>: mov %rsp,%rbp
0x00007ffff7bd59a6 <+4>: movl $0x1,0x200698(%rip) # 0x7ffff7dd6048 <_ZL16hlapiInitialized>
0x00007ffff7bd59b0 <+14>: nop
0x00007ffff7bd59b1 <+15>: pop %rbp
0x00007ffff7bd59b2 <+16>: retq
End of assembler dump.
After comparing the output from hlapi.so and from core file, we know that once the shared library had been loaded into the process, the address of global variable will be reallocated, and the address of the global variables are clear. So, once have the symbol info of the shared library, gdb can map the variables.