This is the mail archive of the gdb@sourceware.org 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]

dwarf2_physname() question


Hello,

With the Cray compiler (CCE), static functions in C are handled by mangling
their name and marking them with external visibility. Take the following
example:

static int ival(void)
{
  int val = 1;
  return val;
}

int main()
{
  int val = ival();
  return val;
}

The dwarf for the ival function produced by CCE looks like the following:

 38564  <1><1e1>: Abbrev Number: 2 (DW_TAG_subprogram)
 38565     <1e2>   DW_AT_name        : ival
 38566     <1e7>   DW_AT_external    : 1
 38567     <1e8>   DW_AT_MIPS_linkage_name: ival$$CFE_id_856de079_main
 38568     <203>   DW_AT_prototyped  : 1
 38569     <204>   DW_AT_decl_file   : 1
 38570     <205>   DW_AT_decl_line   : 1
 38571     <206>   DW_AT_decl_column : 0
 38572     <207>   DW_AT_type        : <0x267>
 38573     <20b>   DW_AT_low_pc      : 0x401040
 38574     <213>   DW_AT_high_pc     : 0x401055
 38575     <21b>   DW_AT_frame_base  : 1 byte block: 57    (DW_OP_reg7 (rsp))
 38576     <21d>   DW_AT_MIPS_fde or DW_AT_HP_unmodifiable: 0x0
 38577     <221>   DW_AT_sibling     : <0x267>

Notice that there is a DW_AT_name and DW_AT_MPIS_linkage_name for the subprogram
DIE. When gdb reads in this DIE and tries to create a new symbol for it in
new_symbol_full(), it will call the dwarf2_physname() function to obtain the
linkage name. That function uses the value of the DW_AT_MIPS_linkage_name and
tries to pass it through the name demangler gdb_demangle(). This doesn't
understand the CCE name mangling scheme, and returns the full linkage name which
is then used as the name of the symbol.

The effect of this is that gdb can only break on the mangled name of the
function for CCE, and not the identifier name as it appears in the source:

(gdb) break ival
Function "ival" not defined.
Make breakpoint pending on future shared library load? (y or [n]) n
(gdb) break ival$$CFE_id_856de079_main
Breakpoint 1 at 0x401040: file test.c, line 3.

My question is why is dwarf2_physname() ignoring the DW_AT_name if it is
present? The DW_AT_name is supposed to represent the identifier name as it
appears in the source. Shouldn't that take priority when gdb creates the
symbol?

Thanks,
Andrew

--
Andrew Gontarek
PE Debuggers


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