This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC 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]

[Bug debug/85550] New: [7/8/9 Regression] -fdebug-types-section broken with DW_OP_addr in DW_AT_location


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.

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