Search code examples
gccgdbclang

What are the dot in variables in "Non-debugging symbols:" in gdb


When gdb the bash executable (compiled with -g), and use info variables to inspect the variables.

I got something like this. There are dots in the symbols. Could anybody help explain what this notiation means?

Non-debugging symbols:
0x0000000100105380  read_alias_file.aliasfile
0x000000010010a320  set_pipestatus_from_exit.v
0x000000010010a458  set_maxchild.lmaxchild
0x000000010010a45c  waitchld.wcontinued
0x000000010010bec4  set_restricted_shell.save_restricted
0x000000010010bed0  internal_getopt.errstr
0x000000010010bedc  rangecmp.s1
0x000000010010bede  rangecmp.s2
0x000000010010bee0  rangecmp_wc.s1

For example, I see both read_alias_file and aliasfile. But I don't know what read_alias_file.aliasfile means.

$ ack read_alias_file
lib/intl/localealias.c
145:static size_t read_alias_file PARAMS ((const char *fname, int fname_len))
205:        added = read_alias_file (start, locale_alias_path - start);
220:read_alias_file (fname, fname_len)
$ ack aliasfile
lib/intl/localealias.c
227:  static const char aliasfile[] = "/locale.alias";
229:  full_fname = (char *) alloca (fname_len + sizeof aliasfile);
232:       aliasfile, sizeof aliasfile);
235:  memcpy (&full_fname[fname_len], aliasfile, sizeof aliasfile);

Solution

  • I don't know what read_alias_file.aliasfile means.

    It's a global variable aliasfile, that is only visible inside read_alias_file function.

    Since you can have same-named variables in multiple files and functions:

    // foo.c
    static int foo = 42;
    
    // bar.c
    int fn1() { static int foo = 43; ... }
    int fn2() { static int foo = 44; ... }
    

    and these variables must have storage throughout the entire program, the compiler has to somehow uniquify them all so the linker doesn't merge them into a single variable.

    Appending a random number, or a hash of file / function name, or the file and function names are common strategies.

    Using file / function name (as your compiler apparently does) makes it easier to tell which foo came from where. You shouldn't depend on this though -- it's completely up to the compiler (so long as resulting names are sufficiently unique at link time).