This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug debug/85550] New: [7/8/9 Regression] -fdebug-types-section broken with DW_OP_addr in DW_AT_location
- From: "jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 27 Apr 2018 11:13:42 +0000
- Subject: [Bug debug/85550] New: [7/8/9 Regression] -fdebug-types-section broken with DW_OP_addr in DW_AT_location
- Auto-submitted: auto-generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85550
Bug ID: 85550
Summary: [7/8/9 Regression] -fdebug-types-section broken with
DW_OP_addr in DW_AT_location
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
struct A {
int bar () const { return 0; }
};
template <int (A::*foo)() const>
struct B {
};
B<&A::bar> b;
int
main ()
{
}
fails to link with -O2 -g -fdebug-types-section starting with r240578.
Without -fdebug-types-section we handle removal of the location attribute or
replacement with something else through resolve_addr, but that can't be really
called when the type units are already split, they are checksummed, so we can't
really modify them.
Wonder what are all the cases where type units need to have DW_AT_location
attribute and what we can do for them, could we e.g. use unconditionally
DW_OP_GNU_variable_value in that case instead of DW_OP_addr? Though, not
really sure if type units can refer to such DIEs.