CODEWITHSUNDEEP
cgccgdblto
user1266174
user1266174

Reputation: 109

GDB: Access name-mangled (.lto_priv) Link Time Optimization (LTO) variables

Our codebase enabled LTO (link time optimization) recently, which name-mangled several static global variables. This breaks several of our Python/GDB macros.

static my_var = 1;

(gdb) p my_var
$1 = <optimized out>

I am looking for a way to correct any LTO mangling so that the macros can operate as they used to.

Our current solution is to remove static when we encounter a macro failure, which isn't the best code practice. And also it is not always reproducible, so fixing them all would be iterative and cumbersome.

At least in one of the cores, I found that if I do a "bt full" on a thread, gdb somehow figures out the non-mangled name, and the script works. Because of that, I was hoping that I could do a "thread apply bt full" as a hack to get static variables working, which didn't work. Also, the single 'bt full' thread has no file relevant to the static variable. So not sure what is going on there.

Found this, and I am able to at least print the data. https://www.tablix.org/~avian/blog/archives/2020/02/printing_lto_priv_symbols_in_gdb/

Was wondering if I could use the following commands to programmatically re-assign all variables that have any lto_priv assignment:

(gdb) whatis my_var
type = my_var_t [128]

(gdb) info variables my_var
All variables matching regular expression "my_var":

File <artificial>:
477:    static my_var_t my_var[128];

File my_file.c:
477:    static my_var_t my_var[128];

Non-debugging symbols:
0x0000555561edb0a0  my_var.lto_priv

(gdb) p (my_var_t [128]) 'my_var.lto_priv.0'
$1 = {{
    ...
  }, {
    ...
  }, {

Think it would work except the assignment below isn't working as I was hoping:

(gdb) set my_var=(my_var_t [128]) 'my_var.lto_priv.0'

Upvotes: 2

Views: 488

Answers (0)

Related Questions