This is the mail archive of the
elfutils-devel@sourceware.org
mailing list for the elfutils project.
Re: dwarflint versus linkage_name attributes
- From: Mark Wielaard <mjw at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Fri, 08 Apr 2011 12:18:25 +0200
- Subject: Re: dwarflint versus linkage_name attributes
On Mon, 2011-04-04 at 07:10 -0700, Roland McGrath wrote:
> > - DW_TAG_variables, which do have a linkage_name, can be found in symtab
> > (not checked by the code, just my manual spot checking), but don't have
> > DW_AT_external set. I think this is just a gcc bug.
>
> If the symbol is STB_LOCAL, then the bug is emitting linkage_name in the
> DWARF where it's not needed. If the symbol is global, then the bug is
> failing to emit linkage_name where it is needed.
Took me some time to figure out "the rules", the following seems to
track what GCC actually emits. Except for the GNU extension for
anonymous struct and enum typedefs I think it matches what dwarf
intended.
commit 5d91a0bf01b7c852e4e578524ee19d8682de5653
Author: Mark Wielaard <mjw@redhat.com>
Date: Fri Apr 8 11:30:58 2011 +0200
dwarflint: check_linkage_external_die keep symbol table and double
check.
We pull the symbol table from the dwarf file and check when a
linkage_name is set that the symbol table contains that name and is
marked not marked local, with the following exceptions:
- No symbol in table, OK, if not a defining or const object.
Or GNU extension, anonymous structs can have a linkage_name.
- Symbol in table marked local, OK if not a defining object
and marked external. Which means it comes from some external
symbol table.
Cheers,
Mark