http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48148
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC|jakub at redhat dot com |jan.kratochvil at redhat
| |dot com
--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-03-16
17:03:58 UTC ---
I believe it is a LTO speciality, I can't imagine how non-lto would end up with
DECL_EXTERNAL with DECL_ABSTRACT_ORIGIN set, so I guess your patch is an
alternative.
Or:
--- dwarf2out.c.jj 2011-03-16 09:37:40.000000000 +0100
+++ dwarf2out.c 2011-03-16 17:28:36.054796163 +0100
@@ -22927,7 +22927,9 @@ resolve_addr (dw_die_ref die)
{
tree tdecl = SYMBOL_REF_DECL (a->dw_attr_val.v.val_addr);
dw_die_ref tdie = lookup_decl_die (tdecl);
- if (tdie == NULL && DECL_EXTERNAL (tdecl))
+ if (tdie == NULL
+ && DECL_EXTERNAL (tdecl)
+ && DECL_ABSTRACT_ORIGIN (tdecl) == NULL_TREE)
{
force_decl_die (tdecl);
tdie = lookup_decl_die (tdecl);
that I'm testing right now. DW_TAG_GNU_call_site won't be very useful in that
case anyway, because if the extern is "read_string.constprop.0" with that
DW_AT_name, I bet the debugger won't be able to match it to the definition DIE
anyway. I think currently for read_string.constprop.0 in the definition CU we
will just have
DW_TAG_subprogram
DW_AT_abstract_origin <read_string DIE>
and not any DW_AT_name (which is thought to be the same as abstract origin's
name, correct for the clones) and no DW_AT_linkage_name (guess it would be
desirable to provide a linkage name if the clone has a different name from the
origin).
