CODEWITHSUNDEEP
c++gdb
Michael Schäfer
Michael Schäfer

Reputation: 175

print variable with type from shared library

I have a program which uses some methods and types from an extern shared library. I want to analyse the binary with the gdb. All works fine. I can step through the program and can print the variables. But if I want to print a struct defined in a header file of the shared library I get the following message

No symbol "_t_TYPE" in current context.

print hierarchy

(gdb) print vType
$3 = (TYPE) 0x7fffe75e69d0
(gdb) print (TYPE) 0x7fffe75e69d0
$4 = (_t_TYPE *) 0x7fffe75e69d0
(gdb) print (_t_TYPE *) 0x7fffe75e69d0
No symbol "_t_TYPE" in current context.

I am not able to compile the library with debug flags or without optimizations.

I know the file is stripped. The result of "file library.so" is:

library: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=3f26c595cb3a940260bb82dfa7ec60094db4928c, stripped

Is there a way to print the structure?

Upvotes: 0

Views: 498

Answers (1)

Employed Russian
Employed Russian

Reputation: 213375

There are two cases to consider:

  1. The type of the struct X is publicly available, but not used by your program.
  2. The type is opaque and private to the library.

In the first case, you can either use a variable of the type struct X somewhere in your program, or use the technique from this answer, to make the definition of struct X available to GDB.

In the second case, the developers of the library truly don't want you to peek into their private implementation details. The only way you can do that is by reverse-engineering code in the library. If you do that, note that the implementation can change even on minor library updates (since this is private implementation detail, changing it doesn't affect the documented API or ABI of the library).

The header file doesn't really help. typedef struct _t_TYPE* TYPE;

Yes: that is a common technique for hiding the implementation.

Upvotes: 1

Related Questions