This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: how long should symbols remain LOC_UNRESOLVED?


David Carlton <carlton@math.stanford.edu> writes:
> * What is the minimal symbol table?  Am I correct in thinking that it
>   contains basic information about those global symbols that the
>   linker needs to know about?  (Which could presumably happen because
>   they're defined in this file or referred to in this file.)

A variable declaration in a C program like this:

    int x;

turns into the following assembly code:

...
    .globl x
            .bss
            .align 4
            .type	x,@object
            .size	x,4
    x:
            .zero	4
... 
	.section	.debug_info
...
	.uleb128 0x4	# (DIE (0x32) DW_TAG_variable)
	.ascii "x\0"	# DW_AT_name
	.byte	0x1	# DW_AT_decl_file
	.byte	0x1	# DW_AT_decl_line
	.long	0x42	# DW_AT_type
	.byte	0x1	# DW_AT_external
	.byte	0x5	# DW_AT_location
	.byte	0x3	# DW_OP_addr
	.long	x
	.uleb128 0x5	# (DIE (0x42) DW_TAG_base_type)
	.ascii "int\0"	# DW_AT_name
	.byte	0x4	# DW_AT_byte_size
	.byte	0x5	# DW_AT_encoding
...

The `x' in the first batch of assembly code is a linker symbol; it has
an address, and an ELF type and size (@object, and 4, in this case).

The second batch of assembly code is a portion of the Dwarf 2
debugging info.  It's a DW_TAG_variable die for the C variable `x'.
The die's DW_AT_location attribute is a location expression that
refers to the linker symbol `x' to give the C variable's address.

So the C variable and the linker symbol are two distinct things that
share a name.  The linker symbol is used, well, for linking; the debug
info is only needed if you want to do source-level debugging.

GDB's minimal symbol table describes linker symbols.

GDB's full symbol table (struct symtab) holds the source-language
symbols.

The partial symbol table (struct partial_symtab) acts as an index of
the full symbol table, allowing us to put off reading the debugging
info from the executable until the user actually asks for it.  We read
full symbols one compilation unit at a time.  The partial symbol table
essentially maps address ranges and identifier names to compilation
units; given a reference to a name or address, we consult the partial
symbol table to decide which compilation unit's full symbols we should
read.

Anyway, in the context of your question, it sounds like GDB is
assuming that if it doesn't have debugging info that explicitly gives
it the address of a static member, then it can take the static
member's name, together with the name of its class, derive the
variable's linker symbol's name, and then look that up in the minimal
symbol table.

   Aside on mangling: you can't have linker symbols with names like
   `C::b', so there are `mangling conventions' for encoding C++ names
   as linker symbol names.  In the old days, `C::b' would be mangled
   as `b__C'.  Now there's a new, improved ABI, which says that C::b
   should be mangled as `_ZN1C1bE'.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]