<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 16, 2024 at 10:20 AM Mark Wielaard via Dwarf-discuss <<a href="mailto:dwarf-discuss@lists.dwarfstd.org">dwarf-discuss@lists.dwarfstd.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
Section 6.2.4.1 Standard Content Descriptions under 1. DW_LNCT_path has<br>
the following description on using DW_FORM_strx forms:<br>
<br>
   In a .debug_line.dwo section, the forms DW_FORM_strx, DW_FORM_strx1,<br>
   DW_FORM_strx2, DW_FORM_strx3 and DW_FORM_strx4 may also be used.<br>
   These refer into the .debug_str_offsets.dwo section (and indirectly<br>
   also the .debug_str.dwo section) because no<br>
   .debug_line_str_offsets.dwo or .debug_line_str.dwo sections exist or<br>
   are defined for use in split objects.<br>
<br>
This confuses me a little, it is as if the strx forms are only allowed<br>
when generating split dwarf. But that doesn't seem to be the intent,<br>
because under 6.2.4.2 Vendor-defined Content Descriptions all DW_FORM_strx<br>
variants are listed without special exceptions.<br>
<br>
So I assume the description under DW_LNCT_path is just to explain that<br>
there isn't a .debug_line_str_offsets section that the DW_FORM_strx<br>
forms can refer to. And that DW_FORM_strx forms are resolved as normal<br>
and can be used in both .debug_line and .debug_line.dwo content<br>
descriptions.<br>
<br>
This leaves the question how to determine the str_offsets_base to use.<br>
This seems to require to lookup the CU DIE(s) that refers to the line<br>
table and see if one of them has a DW_AT_str_offsets_base.<br>
<br>
While this is possible, it isn't very efficient when just parsing the<br>
.debug_line table itself.<br>
<br>
Would it make sense to add the str_offsets_base to the line table<br>
header (for DWARF6)?<br>
<br>
Or am I missing a better/simpler way to handle DW_FORM_strx in<br>
.debug_line tables? Or maybe using DW_FORM_strx forms in the<br>
.debug_line table is not something that is really done (I haven't<br>
actually found any producer which does).<br></blockquote><div><br>Yeah, I think it's not sometihng that's really done - it'd conflict with the "strip everything but .debug_line and .debug_line_str" that was enabled in DWARFv5, with the intent to allow string deduplication of path/directory/file names, while still ensuring that non-line debug info could be stripped while keeping the line table in tact/usable. (in DWARFv4 the line table's strings were in the .debug_line section, so they couldn't be deduplicated, they were moved out to allow deduplication but to a separate section so they could be preserved by stripping tools while still stripping all the other strings (which make up a lotl of debug info))<br><br>strx in non-dwo is there to reduce the number of relocations when referencing a string in a string pool many times - but the line table already has that functionality built in, by numbering the file/directories and referencing them by number in the line table state machine. So there isn't any/much motivation to use a strx encoding - and if there was, we'd want that strx to reference into the line_str section, but we probably wouldn't want to put the line_str_offsets table in a separate section, so it'd end up in the .debug_line section, and... we already have that numbering system in there. <br><br>So, yeah, if it's not already clear enough -probably just forbidding strx in non-dwo line tables would be OK?</div></div></div>