llvm dev - Feb 2020 - Debug_line.dwo not present in dwo object.

Hello everyone,

As I was wrapping up my implementation of macro dwo section. I noticed that
debug_line.dwo is not present in dwo object, it's *only* present if type
units are also present.

While spec doesn't mandate the presence of debug_line.dwo section for when
macro section is present, but I think based on comments by Paul in
https://reviews.llvm.org/D72828
At least skeletal .debug_line.dwo section (which contains only the
specialized header (the header and the file and directory lists, but not
the actual line table),  should be present for filenames. Same as in case
of type units, a specialized debug_line.dwo is present.

I would like to have your/community thoughts on this.

Presence of specialized line table also enhances dwarfdump's  readiibilty
while reading DW_AT_decl_file from a DWO object, it only shows[even in
verbose mode] the file number, *not*  the name of the file. Perhaps it
tried  looked for the corresponding entry in debug_line.dwo which is
absent. For the primary object dwarfdump  DW_AT_dec_file attribute is more
readable with the file number and the file name both present.

Thanks a lot!
Sourabh Singh Tomar
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200203/9d18868f/attachment.html>

Yes, it looks like, as Paul pointed out, using DW_MACRO_start_file requires
the debug_macro contribution to have a debug_line_offset ("If a
DW_MACRO_start_file entry is present, the header contains a reference to
the .debug_line section of the compilation." - 6.3.3.1p1 in DWARFv5). Using
DW_MACRO_start_file seems relevant/useful, so emitting debug_line_offset
does too.

Yes, this means expanding the support for debug_line.dwo from the support
for type units, to also supporting the macro usage. It's probably a matter
of renaming the SplitTypeUnitFileTable to, say, SplitFileTable, and using
that from the debug_macro emission code as needed in the same way as it's
done for type units.

I don't think it makes sense to/is correct to generalize this to be used by
compilation units (they need to refer to the debug_line in the .o file to
attach the main line table information - the instruction<>line mapping -
and that cannot be moved into the .dwo file (well, isn't spec'd to be
done
that way and there are various reasons not to want to move it out of the
.o/linked executable, etc)), so decl_file will still be unresolved when
dumping a dwo/dwp in isolation.

On Sun, Feb 2, 2020 at 1:29 PM Sourabh Singh Tomar <sourav0311 at
gmail.com>
wrote:
> Hello everyone,
>
> As I was wrapping up my implementation of macro dwo section. I noticed
> that debug_line.dwo is not present in dwo object, it's *only* present
if
> type units are also present.
>
> While spec doesn't mandate the presence of debug_line.dwo section for
when
> macro section is present, but I think based on comments by Paul in
> https://reviews.llvm.org/D72828
> At least skeletal .debug_line.dwo section (which contains only the
> specialized header (the header and the file and directory lists, but not
> the actual line table),  should be present for filenames. Same as in case
> of type units, a specialized debug_line.dwo is present.
>
> I would like to have your/community thoughts on this.
>
> Presence of specialized line table also enhances dwarfdump's 
readiibilty
> while reading DW_AT_decl_file from a DWO object, it only shows[even in
> verbose mode] the file number, *not*  the name of the file. Perhaps it
> tried  looked for the corresponding entry in debug_line.dwo which is
> absent. For the primary object dwarfdump  DW_AT_dec_file attribute is more
> readable with the file number and the file name both present.
>
> Thanks a lot!
> Sourabh Singh Tomar
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200203/21e5cbc1/attachment.html>