Re: Problems with dwarf-getmacros test

[Ulf Hermann <ulf dot hermann at qt dot io>]

> 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