This is the mail archive of the
mailing list for the elfutils project.
Re: Problems with dwarf-getmacros test
- From: Ulf Hermann <ulf dot hermann at qt dot io>
- To: Mark Wielaard <mark at klomp dot org>
- Cc: <elfutils-devel at sourceware dot org>
- Date: Tue, 9 May 2017 16:11:13 +0200
- Subject: Re: Problems with dwarf-getmacros test
- Authentication-results: sourceware.org; auth=none
- Authentication-results: sourceware.org; dkim=none (message not signed) header.d=none;sourceware.org; dmarc=none action=none header.from=qt.io;
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qtcompany.onmicrosoft.com; s=selector1-qt-io; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VZUSu3xFNR1g185ezb1UgxcEvHcT8fUInXpwA2IIb8k=; b=mhRVWDcE4N3FqLBEISc8gYZ+mZCdAyVMWyDTOiSgNTg1srNJ3tRLpPOSWIaEhMA4GDKSwcQ/qDzeca0iEha+Z3/uzQGyAFRdKRQi2LwPt+d6seAOGQhVuA0OOF/VI2xNDqtPxqABu/1uN7SHlZ53UNzAuiABe9yCOwUsA3u9S18=
- References: <firstname.lastname@example.org> <email@example.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
> 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.