> Is it only with testfile-macros? > All other testfiles always run correctly?
Yes, it only happens with the testfile-macros check at 0xb. > Do you have the whole call stack of that failed __libdw_read_offset > call? Which source line in tests/dwarf-getmacros.c prints the "(null)"? I'm having a hard time triggering the problem in a controlled environment. So far I didn't manage to create a stack trace. The (null) is the result of passing a value of null to dwarf-getmacros.c:88. I get an errno of DWARF_E_INVALID_OFFSET at the assert failure. So I put some debug messages into all places where that is generated and this is how I found the source of this. It seems I can't trigger the effect if I put the debug output directly into __libdw_in_section (but maybe I was just very unlucky). If I put it in READ_AND_RELOCATE I can see that the check always fails before it outputs (null) or hits the assertion. >> Experiments show that the address is >> frequently not in the section we're checking there, but still valid. >> Just dropping the check makes the test succeed. > > I think this might be related to our "fake" CU and attributes we invent > in libdw/dwarf_getmacros.c (read_macros). See around this comment: > > /* We pretend this is a DW_AT_GNU_macros attribute so that > DW_FORM_sec_offset forms get correctly interpreted as > offset into .debug_macro. */ > > If that is the issue then we might need to somehow make > READ_AND_RELOCATE and/or __libdw_in_section aware that the CU is fake > and the check isn't needed. In which case we probably need to add some > flag "fake" to the CU and pass the CU to the various __libdw_read_* > functions to disable that sanity check in READ_AND_RELOCATE. We don't set type_offset on the fake_cu, but we read it via cu_sec_idx when calling __libdw_read_offset from dwarf_formstring. This seems wrong. Ulf
