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

[Will Hawkins <hawkinsw@obs.cr>]

On Sun, Apr 14, 2024 at 3:01 AM Tom de Vries <tdevries@suse.de> wrote:
>
> 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".

Interesting. So, as I understand it, forcing CUs for the file being
compiled (hello.c in the example you cited) to be somewhere other than
the beginning of the .debug_info sections allowed you to catch
additional bugs. In order to draw out similar bugs on platforms where
the "main" CU goes first by default, you added the dummy CU feature.
Am I understanding that correctly? If so, that's really neat.

I will file a bug and then work on PR that makes the dummy cu feature
"compatible" with llvm-dwarfdump. It could obviously also be an issue
with the llvm-dwarfdump tool, too. I have contributed to LLDB, too,
and would be more than happy to work with them if the problems is
really in their tool.

Thank you for the follow up!
Will


>
> Thanks,
> - Tom
>