public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* dwarf2_physname() question
@ 2014-10-15 17:03 Andrew Gontarek
  2014-10-17  9:37 ` Yao Qi
  0 siblings, 1 reply; 2+ messages in thread
From: Andrew Gontarek @ 2014-10-15 17:03 UTC (permalink / raw)
  To: gdb

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: dwarf2_physname() question
  2014-10-15 17:03 dwarf2_physname() question Andrew Gontarek
@ 2014-10-17  9:37 ` Yao Qi
  0 siblings, 0 replies; 2+ messages in thread
From: Yao Qi @ 2014-10-17  9:37 UTC (permalink / raw)
  To: Andrew Gontarek; +Cc: gdb

Andrew Gontarek <andrewg@cray.com> writes:

> 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?

DW_AT_name is there but may be broken, GDB has to rely on
DW_AT_MIPS_linkage_name.  I am not very sure on this, so people who are
more familiar on dwarf can give comments on top of mine.

I find some discussions on this thread, and it may help

  [RFA] dwarf2_physname FINAL
  https://sourceware.org/ml/gdb-patches/2010-03/msg00220.html

-- 
Yao (齐尧)

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2014-10-17  9:37 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-10-15 17:03 dwarf2_physname() question Andrew Gontarek
2014-10-17  9:37 ` Yao Qi

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).