[Dwarf-Discuss] Segment selectors for the range list table.

[David Blaikie]

On Thu, Jul 16, 2020 at 2:05 PM Michael Eager <eager at eagercon.com> wrote:

> On 7/16/20 1:36 PM, David Blaikie wrote:
> >
> >
> > On Thu, Jul 16, 2020 at 1:07 PM Michael Eager <eager at eagercon.com
> > <mailto:eager at eagercon.com>> wrote:
> >
> >      > Perhaps it's more like Paul was postulating - that the spec
> >     assumes code
> >      > is in a code segment/doesn't need to be clarified. (but that gets
> >     a bit
> >      > confused in debug_aranges - if it only is meant to contain code
> (not
> >      > data), why does it need a segment selector - and also in the DIEs
> >     - if
> >      > code is always in a known/assumable segment then why can you vary
> >      > segment for low_pc/high_pc/ranges?)
> >
> >     No, the spec says what it says.   There are no restriction on where
> >     code
> >     or data are located.
> >
> >
> > OK - then if subprograms can be in different segments, how would the
> > ranges on the CU be used to describe that? It seems to me that a range
> > list can't contain regions in more than one segment, which presents a
> > problem for describing such a situation, no?
>
> You appear to be starting with a counterfactual premise and using that
> to postulate a problem where none exists.
>

Sorry - I seem to be misunderstanding what you mean by "there are no
restrictions on where code or data are located" - I understood that to mean
different bits of code could be in different segments.


> As previously stated, DW_AT_segment provides a way to represent x86
> segmented addressing.  Each segmented address is mapped to an address in
> a linear address space.  The mapped address can be used in the ranges.
>

Where does the spec say that? How do we construct an answer to the original
question from this thread from the words in the spec?


>
> > (speaking of header consistency - it's a pity the debug_macro section
> > didn't end up with a more consistent header that started with a length,
> > then a version - without the length prefix it'll be hard to skip over
> > these in a consumer (especially something like a dumper) if their
> > version is unknown (in future versions, for instance))
>
> Rather than lard a thread with extraneous comments about unrelated
> issues, submit a comment on the DWARF Standard Public Comment page:
> http://dwarfstd.org/Comment.php


Fair point, for sure - sorry about that. Done.


>
>
> >      > debug_addr supports segment selectors - in the debug_addr header
> >     it has
> >      > a field for "segment selector size" and the entries in the
> >     address list
> >      > are "segment/address pairs.".
> >      >
> >      > So now there's two ways a segment selector for an address could be
> >      > specified - if you had a DW_TAG_subprogram with a DW_AT_low_pc
> using
> >      > addrx into a debug_addr with a non-zero segment selector and the
> >      > subprogram also had a DW_AT_segment, wonder which one's meant to
> win.
> >
> >     Again, FORM_addrx doesn't mean the same as DW_AT_segment.
> >
> >
> > The spec seems to use exactly the same language. All the addresses seem
> > to say they only contain the offset portion of the address - so they'd
> > all need a segment selector to resolve which segment they should be
> > relative to, right? But some of them don't have a segment selector -
> > though the spec says loc/range/etc should be relative to the segment on
> > the DIE that references the loclist/rnglist/address - but then the
> > debug_addr has redundant (or possibly contradictory... ) segment
> > selectors and the range/loclists could only describe things in one
> > segment (so you couldn't use CU ranges to describe one function in one
> > segment and another function in a different segment)
>
> There are always ambiguities in written text.  If you have a specific
> comment about wording in the DWARF Specification, please submit a Public
> Comment.


I don't especially have a need for segmented addresses myself - so I may
not be the best person to push for changes/clarifications here - I was
trying to answer the original poster's question using what I can see from
the spec.

>     They are orthogonal concepts.  Compression techniques, like
> FORM_addrx,
> >     should not be used to describe architectural features.
> >
> >
> > I agree there clearly shouldn't be something you can express in a
> > debug_rnglist or debug_loclist (or a DIE attribute using FORM_addrx)
> > with the *x forms that you can't describe with the non-*x forms, but
> > from the semantics represented, it looks like that's the case, even if
> > it's not how it should be.
>
> There are no semantics represented in DWARF.
>

Semantics in the sense that a range list can refer to an address and that
address can have a segment selector. The meaning of the bits in the file -
not higher level semantics of "what is a class" (whatever a producer and
consumer agree that it is) but "these bits are specified to describe a
range using this address and this address has a segment selector".

You appear to be reading the standard to mean something other than what
> it says.  FORM_addrx is a method to compress FORM_addr, nothing more.
>

But it describes segmented addresses - it says so specifically, doesn't it?
Using the same wording that is used to describe segmented addresses
elsewhere in the spec.

> I think the language that's missing in debug_loclists/debug_rnglists (&
> > was missing from debug_range/debug_loc too) is that the addresses should
> > be preceeded by their segment - same as debug_aranges and debug_frame?
> > (& in rnglist/loclist, the segment selector would go in any form that
> > has an address in it)
>
> Please file a Public Comment.
>

 Done.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/attachments/20200716/5c49b96f/attachment.html>