[Dwarf-Discuss] Split Dwarf vs. CU DW_AT_ranges / DW_AT_low_pc placement

[David Blaikie]

On Thu, Mar 11, 2021 at 11:44 AM Jakub Jelinek <jakub at redhat.com> wrote:

> On Thu, Mar 11, 2021 at 11:30:05AM -0800, David Blaikie wrote:
> > Thanks! - is this proposed as a DWARF extension? I thought I remembered
> it
>
> 170427.1 I think.  Note, what is emitted is different from what is being
> proposed, the problem with DW_LLE_* and DW_RLE_* is that they aren't easily
> extensible (in a way that would allow consumers that don't know about the
> extension skip it and parse just the standard ones; because when seeing
> an unknown opcode, the consumer doesn't know what arguments if any it has).
> E.g. in the way .debug_macro allows producers to define what arguments
> extension opcodes have (how many and what DW_FORM_* each has).
> So I think what GCC currently produces puts the stuff before the location
> sequences such that if a consumer can't handle those, it can skip those.
>

Ah, cunning! Yeah, there's a few places where LLVM just keeps trying to
parse the next thing, rather than only parsing parts that are referenced
from elsewhere (the other one I know of is a bug in location lists when
combined with bfd's linker tombstoning of gc'd sections (it sets any
relocation to a gc'd section to zero): if a location list were to span
across a gc'd section (such as for a global, raised into a register in one
function - LLVM can't produce the right DWARF for this, not sure about GCC)
binutils readelf, etc, will only dump sections of debug_loc that are
referenced from .debug_info, so the early list termination just leaves
holes, rather than mangled parsing trying to interpret the location
expression following the accidental terminator as the start of another
location list)


> The only thing that doesn't really work well for consumer unaware about
> that
> extension is walking the whole .debug_rnglists and dumping everything that
> it contains.
>

Yup - yeah, LLVM will just try to parse each offset and then go to the next
one, etc. (I don't think lldb would do this, hopefully - this is only an
issue with llvm-dwarfdump trying to dump as much as possible)

- Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/attachments/20210311/6c6e7ca7/attachment-0001.html>