RE: [PATCH 2/2] Test script modifications to use llvm-dwarfdump when compiler is clang

["E, Nagajyothi" <Nagajyothi.E@amd.com>]

[AMD Official Use Only - Internal Distribution Only]

Hi,

Does anyone have any comments on these patches? A gentle reminder for review.

Thanks,
Nagajyothi

-----Original Message-----
From: E, Nagajyothi <Nagajyothi.E@amd.com>
Sent: Sunday, May 16, 2021 5:06 PM
To: Mark Wielaard <mark@klomp.org>; dwz@sourceware.org
Cc: George, Jini Susan <JiniSusan.George@amd.com>; Achra, Nitika <Nitika.Achra@amd.com>; Sharma, Alok Kumar <AlokKumar.Sharma@amd.com>; Parasuraman, Hariharan <Hariharan.Parasuraman@amd.com>; E, Nagajyothi <Nagajyothi.E@amd.com>
Subject: [PATCH 2/2] Test script modifications to use llvm-dwarfdump when compiler is clang

[AMD Official Use Only - Internal Distribution Only]

Hi,

This testsuite patch may be used while running
	 make check CC="clang -gdwarf-5" CXX="clang++ -gdwarf-5"
to avoid test failures due to readelf.

This checks if $CC/$CXX is clang/clang++ and uses llvm-dwarfdump in place of readelf in the test scripts. This is needed as readelf produces errors/warnings with clang-generated DWARF5 sections/forms, causing many test failures. The latest llvm-dwarfdump (27 April, 2021) is to be used, which has a fix in printing headers of DW_UT_partial type.

Thanks,
Nagajyothi

-----Original Message-----
From: Mark Wielaard <mark@klomp.org>
Sent: Thursday, February 18, 2021 8:15 PM
To: E, Nagajyothi <Nagajyothi.E@amd.com>; dwz@sourceware.org
Cc: George, Jini Susan <JiniSusan.George@amd.com>; Achra, Nitika <Nitika.Achra@amd.com>; Sharma, Alok Kumar <AlokKumar.Sharma@amd.com>
Subject: Re: Plan to contribute for supporting split dwarf (-gsplit-dwarf) in dwz

[CAUTION: External Email]

Hi Nagajyothi,

On Wed, 2021-02-17 at 05:53 +0000, E, Nagajyothi via Dwz wrote:
> I am working on adding support for the dwarf5 .debug_str_offsets, 
> .debug_addr sections and the related forms DW_FORM_strx[1234], DW_FORM_addrx[1234].
> Please let me know if anyone has already started work on these.

Thanks, I don't believe anybody is working on this right now.

There is already a bug for .debug_addr/DW_FORM_addrx[1234] support:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceware.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D27375&amp;data=04%7C01%7CNagajyothi.E%40amd.com%7C37c0fb4399464264b01808d8d41bcb9c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637492563147320988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=7AjB%2BXKo9J5gTlW1CeEhHXZykYKB2vFZ%2BTnBQvW4%2BIA%3D&amp;reserved=0
I think this shouldn't be too hard. Any DIE that references an address cannot be moved to an alt file, so simply mark it with die_no_multifile. We do try to optimize DW_AT_low/high_pc attribute pairs, so double check that doesn't interfere with DW_FORM_addrx[1234] processing.

Also note that there are two new location operations DW_OP_addrx and DW_OP_constx that can reference the .debug_addr section index.

As a followup you could try optimizing things, but then you need to keep track of all the addresses used and see if there are duplicates that could be turned into a (smaller) DW_FORM_addrx[1234] index. But I would keep that separate from the initial implementation.

For .debug_str_offset/DW_FORM_strx[1234] I opened a new bug.
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceware.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D27434&amp;data=04%7C01%7CNagajyothi.E%40amd.com%7C37c0fb4399464264b01808d8d41bcb9c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637492563147330979%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=AqQRLjgKh9h7YHPIr4wDiqP1rRTXz2kG6IZlAT0SaSQ%3D&amp;reserved=0

This is a little trickier than DW_FORM_addrx[1234] since such DIEs using DW_FORM_strx may be moved to a multifile. You also probably want to make them equal to DW_FORM_strp entries pointing (indirectly) to the same string.

You might want to add a note to the the bugs that you are working on them.

Thanks,

Mark