RetroSearch Browse

Wed Jul 22 00:05:10 PDT 2020 · https://lists.llvm.org/pipermail/llvm-dev/2020-July/143622.html

Great, thanks! I'll look at a patch in due course (it may need to wait for
me to finish other bits first).

James

On Tue, 21 Jul 2020 at 19:31, David Blaikie <dblaikie at gmail.com> wrote:

> Yep, sounds like a reasonable bug in llvm-dwarfdump to fix.
>
> Probably the right way to fix this is to check whether the start/end
> addresses have a section number. If they're zero with no section number,
> then they're really zero & should terminate the list. Otherwise they
> shouldn't.
>
> Here's a reproducer for debug_ranges at least, without needing any patches
> to LLVM:
>
> $ cat range.cpp
> void f1() { }
> void f2() { __builtin_unreachable(); } // alternatively: "int f2() { }" -
> both constructs are valid so long as f2 is never called, though it may
> still need to have a valid address (could use pointers to it in a map for
> some reason, etc)
> int main() { }
> $ clang++ range.cpp -ffunction-sections -g -O1 -c
> $ llvm-dwarfdump-tot range.o -debug-info -debug-ranges
> range.o:        file format elf64-x86-64
>
> .debug_info contents:
> 0x00000000: Compile Unit: length = 0x00000079, format = DWARF32, version =
> 0x0004, abbr_offset = 0x0000, addr_size = 0x08 (next unit at 0x0000007d)
>
> 0x0000000b: DW_TAG_compile_unit
> ...
>               DW_AT_ranges      (0x00000000
>                  [0x0000000000000000, 0x0000000000000001))
> ...
> .debug_ranges contents:
> 00000000 0000000000000000 0000000000000001
> 00000000 <End of list>
> 00000020 0000000000000000 0000000000000003
> 00000020 <End of list>
> $ llvm-dwarfdump-tot a.out -debug-info -debug-ranges
> a.out:  file format elf64-x86-64
>
> .debug_info contents:
> 0x00000000: Compile Unit: length = 0x00000079, format = DWARF32, version =
> 0x0004, abbr_offset = 0x0000, addr_size = 0x08 (next unit at 0x0000007d)
>
> 0x0000000b: DW_TAG_compile_unit
> ...
>               DW_AT_ranges      (0x00000000
>                  [0x0000000000401110, 0x0000000000401111)
>                  [0x0000000000401120, 0x0000000000401120)
>                  [0x0000000000401120, 0x0000000000401123))
> ...
>
> .debug_ranges contents:
> 00000000 0000000000401110 0000000000401111
> 00000000 0000000000401120 0000000000401120
> 00000000 0000000000401120 0000000000401123
> 00000000 <End of list>
>
>
> On Tue, Jul 21, 2020 at 8:29 AM Robinson, Paul <paul.robinson at sony.com>
> wrote:
>
>> I agree itâs a bug.  An absolute (0, 0) pair is what indicates
>> end-of-list.  You can get pairs of 0 addends with `.quad foo; .quad foo` or
>> `.quad foo; .quad bar` but the former is an empty range and the latter
>> would be a real range.
>>
>> Iâd expect the identical issue to pop up in .debug_ranges, so a patch
>> should address both.
>>
>> --paulr
>>
>>
>>
>> *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> *On Behalf Of *James
>> Henderson via llvm-dev
>> *Sent:* Tuesday, July 21, 2020 4:26 AM
>> *To:* llvm-dev <llvm-dev at lists.llvm.org>; David Blaikie <
>> dblaikie at gmail.com>; Alexey Lapshin <a.v.lapshin at mail.ru>
>> *Subject:* [llvm-dev] [DWARF] Handling empty ranges/location lists in
>> ET_REL files
>>
>>
>>
>> Hi all,
>>
>>
>>
>> I've put this email in a different thread, although it is quite similar
>> to some of the threads on tombstoning etc, with similar underlying
>> structural issues.
>>
>>
>>
>> Whilst prototyping my fragmented DWARF idea for GC-ing DWARF sections
>> properly, I ran into an object in the game code I was using as my input
>> where a v4 .debug_loc section had a location description that looked
>> something like this:
>>
>>
>>
>> .quad foo
>>
>> .quad foo
>>
>> ... # location description
>>
>>
>>
>> where foo was a section symbol, i.e. the start and end address were the
>> same. Consequently, there would be two relocations with 0 addend patching
>> the start and end offset. When I was using llvm-dwarfdump to dump the
>> .debug_loc section, I ended up with a decoding, and eventually a parsing
>> error, because it saw a 0, 0 pair, so treated the entry as an end of list
>> entry, and assumed the location description was the start of the next list.
>>
>>
>>
>> The debug_loc parsing code treats 0, 0 pairs as end of list entries,
>> whether or not they are relocated. I think this is a bug - if there are
>> relocations we can be reasonably confident that the compiler did not intend
>> it to be the end of the list, and at link time, this probably won't get
>> resolved to 0, 0 (it's still technically possible it will, if 0 is a valid
>> address, and the corresponding section was put at that address, but that's
>> outside the scope of this email).
>>
>>
>>
>> I've got a fairly simple change that could solve this, but it would
>> require to check for the presence of a relocation at either address, in the
>> event 0, 0 was read. Should I go ahead with tidying up the change/testing
>> it etc? Or do we want a different solution to this problem (aside from
>> using DWARFv5 of course!)?
>>
>>
>>
>> Related aside: I haven't checked, but it's quite possible there's a
>> similar problem in .debug_ranges parsing.
>>
>>
>>
>> James
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200722/4d08d145/attachment.html>

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://lists.llvm.org/pipermail/llvm-dev/2020-July/143622.html below:

[llvm-dev] [DWARF] Handling empty ranges/location lists in ET_REL files