Re: [Dwarf-discuss] [DWARF5] .debug_names + fdebug-types-sections

[David Blaikie via Dwarf-discuss]

On Fri, Sep 15, 2023 at 2:45 PM Alexander Yermolovich via
Dwarf-discuss  wrote:
>
> Hello
>
> I am trying to enable debug names acceleration table with 
> fdebug-types-sections in LLVM. One part I am not sure about is the local TU 
> list. It contains an offset into .debug_info section. All the entries have an 
> index entry that points to the local TU list. DIEs within entry offsets are 
> relative to the TU entry.
>
> Linker de-duplicates Type Units using COMDAT. So, the final result will have 
> less type units. As the result Local Type Unit List will be invalid, and all 
> the Entries that point to that TU will not be valid either. Even if we Linker 
> is modified so that somehow when it de-duplicates type sections Local Type 
> Units will get the right offset, that still leaves all the duplicate entries.
> Am I missing something in that linker, specifically LLD, will need to be 
> aware of context of .debug_names sections when it de-duplicates type sections?
>
>
> It seems to me that to fully support it .debug_names need to be created by 
> post build tool (or by linker).
>
> Thanks.

While DWARF consumers will benefit from a content-aware linking of
.debug_names (using one hash table is more efficient than probing
hundreds/thousands of small hash tables), I don't believe the spec
as-is requires that for correctness.

In the case of type units, I'd expect behavior somewhat similar to how
linkers behave with inline functions - if the two copies of the
function are identical, it's possible that the linker will resolve all
relocations to the function to the single copy that remains after
linking (so two CUs would both describe the inline function "f1" and
both descriptions would have the same start address/length, the two
CUs CU-level DW_AT_ranges would overlap/both contain that function's
addresses - and neither would use the tombstone address). So in that
case, all the duplicate index entries would remain valid (their
TU-relative offsets would be correct - since the TUs were bit-wise
identical, so the offsets still point to the same things).

In the case where a producer produces equivalent but not
bitwise-identical TUs, the linker will choose one, drop the rest, and
use the tombstone value to resolve the relocation used in the local
TUs offset list. A consumer should ignore any entries that reference a
tombstone offset in the local TU list (& probably wouldn't hurt to use
the same code and ignore any tombstoned CUs too - I can't immediately
think of a situation/reason that'd happen, but seems like a good
general idea)

If a consumer does a semantic aware merge of the indexes, then it
should discard (rather than tombstoning) the index entries that
reference dead TUs and the dead TUs in the local TU list itself, and
also discard any duplicate index entries and duplicate elements in the
local TU list.

We could document the use of the tombstone in this context.
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

Re: [Dwarf-discuss] Facing a issue in contents of dwarf debug info section in an ELF file

[Kyle Huey via Dwarf-discuss]

Most likely the .debug_info section is SHF_COMPRESSED. Try compiling with
-gz=none.

- Kyle

On Mon, Sep 25, 2023, 1:36 PM Rishi Raj via Dwarf-discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:

> 
>
> I am trying to implement a dwarf parser in C++ without using any external
> dependencies. As mentioned in dwarf5 standard, debug info first 4 bytes or
> 12 bytes denotes the unit length Basically this:
>
> unit_length (initial length)
> A 4-byte or 12-byte unsigned integer representing the length of the3
> .debug_info contribution for that compilation unit, not including the length 
> field itself. In the 32-bit DWARF format, this is a 4-byte unsigned integer 
> (which must be less than 0xfff0); in the 64-bit DWARF format, this 
> consists of the 4-byte value 0x followed by an 8-byte unsigned 
> integer that gives the actual length (see Section 7.4 on page 196).
>
> When I am dumping the .debug_info section hexadecimally using objdump I am
> getting this(see readelf output below).
>
> objdump -s -j .debug_info hello.o
>
> hello.o: file format elf64-x86-64
>
> Contents of section .debug_info:
>
>   0100  9a00   
>  0010 0100  789c9bc6 c0c0c0ca  x...
>  0020 c0c801a4 18984084 2c031a10 42623372  ..@.,...Bb3r
>  0030 b0832916 0805d1c6 c804e5b1 4178ac20  ..).Ax.
>  0040 8a998535 33af04a8 8115498e 05aa2002  ...53.I... .
>  0050 8bf18c73 58131918 99394172 4c137318  ...sX9ArL.s.
>  0060 180011e5 0560
>
> So according to this, the length should be 0x0100, but the actual
> length is 0x96.(see readelf output below)
> readelf -wi hello.o
> Contents of the .debug_info section:
>
> Compilation Unit @ offset 0:
> Length: 0x96 (32-bit)
> Version: 5 Unit Type: DW_UT_compile (1) Abbrev Offset: 0
> Pointer Size: 8
>
> I know I am missing something basic, but even after reading the standards
> for many times. I am unable to find my mistake. One more thing, I searched
> for some basic dwarf parsers so that I could understand what they are doing
> but could not find any. All of the parsers were big libraries, which was
> difficult to understand. If any of you can at least provide some readable
> and understandable parser code, It will be helpful too.
>
> ELF header dump:
>
> ELF Header:
>   Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
>   Class: ELF64
>   Data:  2's complement, little endian
>   Version:   1 (current)
>   OS/ABI:UNIX - System V
>   ABI Version:   0
>   Type:  REL (Relocatable file)
>   Machine:   Advanced Micro Devices X86-64
>   Version:   0x1
>   Entry point address:   0x0
>   Start of program headers:  0 (bytes into file)
>   Start of section headers:  3048 (bytes into file)
>   Flags: 0x0
>   Size of this header:   64 (bytes)
>   Size of program headers:   0 (bytes)
>   Number of program headers: 0
>   Size of section headers:   64 (bytes)
> --
> Dwarf-discuss mailing list
> Dwarf-discuss@lists.dwarfstd.org
> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
>
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss