Re: [PATCH v5] gdb: Support embedded source in DWARF

[Tom de Vries <tdevries@suse.de>]

On 4/14/24 04:50, Will Hawkins wrote:
> On Fri, Apr 12, 2024 at 4:12 PM Tom de Vries <tdevries@suse.de> wrote:
>>
>> On 4/12/24 20:55, Will Hawkins wrote:
>>> +         DW_LNE_set_address main_end
>>> +         line [gdb_get_line_number "main end"]
>>> +         DW_LNS_copy
>>> +
>>> +         DW_LNE_end_sequence
>>> +     }
>> I've just submitted a patch series designed to catch this (
>> https://sourceware.org/pipermail/gdb-patches/2024-April/207922.html ).
>>
>> The copy produces a line table entry with empty address range (because
>> the end_sequence is at the same address),.
>>
>> This is probably not what you intended.
> 
> What I get for doing copy/paste! A v6 is on its way! Thank you for the
> eagle eyes!
> 

It's just that I spent some time fixing all test-cases with this 
problem, so I happened to spot it.  Anyway, thanks for following up.

> On a semi-related note, it appears that "many" of the dwarf2 tests do
> not properly specify
> 
> add_dummy_cus 0
> 
> in their invocation of Dwarf::assemble resulting in two CUs being
> generated in the .S file. This does not appear to cause problems for
> the tests, but if you run the generated binaries through a "dwarf
> validator", e.g., llvm-dwarfdump, they will report errors. I have
> requested an account on the gdb bugzilla to report a bug and will file
> a related patch as a fix, if that is okay with you?

The dummy cu's are there by default, intentionally, as explained here ( 
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=5ef670d81fd222ae5edfa1428ad48710f5e10d35 
).  In brief, it tries to make sure that when writing a dwarf assembly 
test-case on one platform it will work on another.

If this causes problems with llvm-dwarfdump, we can look into fixing 
that.  So, yes, please file a PR.

But I'd look into a way of fixing this that doesn't require 
"add_dummy_cus 0".

Thanks,
- Tom