[llvm-dev] [DWARFv5] Reading the .debug_str_offsets section

[David Blaikie via llvm-dev]

On Thu, Jul 6, 2017 at 1:04 PM Robinson, Paul <paul.robinson at sony.com>
wrote:

> I mean, you could identify which CU points to that line table header,
>
> Guess that was str_offsets header - but if you're only dumping the
> str_offsets you wouldn't need to know which CU points to it, and if you're
> trying to resolve a str_index form in a CU, you know which CU you're in &
> can use its str_offsets_base (+contribution range start), if present - same
> as in non-DWO cases.
>
> No, I meant line table header… what you're saying is all fine for dumping
> a str_offsets section, or resolving a strx form in a CU, but I'm trying to
> resolve a strx in a line-table header in a DWO.  Maybe that wasn't clear,
> but that's where I'm headed.
>

Ah, right, thanks for the reminder/framing.

Could do something sort of similar in a DWO file, even without finding the
CU. I'm guessing the line table can have something like the
str_offsets_base in it (for non-fission cases, at least)? In any case, even
without str_offsets_base for the line table, to find the right str_offsets
contribution a dumper or other parser would have to find the list of
contributions for the unit covering this line table (easiest if they start
from a CU and can use the CU hash to lookup in the cu_index - but if not,
it'd have to linearly search (or build its own in-memory fast lookup after
reading the whole index) through the index until it finds an entry with a
line section rangef that covers the current line table being parsed)) -
then it can resolve a str_offsets_base, if present, relative to that
contribution - doesn't seem like that adds a lot more work & indeed could
come out relatively naturally from the non-DWO support anyway.

- Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170706/3f5d1cf1/attachment.html>