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

[David Blaikie]

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

> On 7/16/20 2:57 PM, David Blaikie wrote:
> >
> >
> > On Thu, Jul 16, 2020 at 2:05 PM Michael Eager <eager at eagercon.com
> >
> >     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.
>
> It does no one good when you take a comment about one point
> (.debug_aranges) and contort it to apply to an unrelated point
> (DW_AT_segment).
>

The language used to describe segmented addressing in DW_AT_segment reads
to me like the same language used to describe segmented addresses in
debug_aranges - it reads to me like they refer to the same concept. What
aspect of the wording do you find distinguishes between these two
discussions on segmented addresses?


> Reread my previous comment about the meaning of segment as used in
> DW_AT_segment.   You apparently want it to mean something different.
>

There seems to be some significant disconnect between how we're each
understanding these concepts - could you help me understand/perhaps use
different language that might help me understand/connect with your
reading/understanding here? I'm trying my best to understand what the spec
is saying/how to interpret it.

>     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?
>
> There are many things that the spec does not say about implementation.
> We sometimes suggest best practices, but we don't require implementors
> to follow them.  The DWARF spec is also not written to prevent
> implementors from doing things badly.
>
> Providing an example of the use of DW_AT_segment provides a strong hint
> of how it may be used, without constraining it to one specific
> architecture, or preventing it from being used in other ways.  When we
> have had discussions about whether to give more specific implementation
> details, we have frequently decided to let matters go with a hint,
> rather than a prescription.
>
> While we cannot prevent people from misreading or misinterpreting the
> DWARF spec, we try to answer questions as they arise.
>
> Having been told how address ranges might be implemented for x86
> segmented addresses, is there more to add?
>

You've mentioned they can be used - but I'm still pretty confused by how
they would be used to achieve that result. Do you happen to know of an
implementation that uses them in this way/any examples of DWARF using the
feature? I think that'd be realyl helpful to ground the discussion with
concrete examples.

My reading still seems to indicate that all the dwarf sections are meant to
use segment-relative addresses (all the wording for address size says it
should be the segment-relative address size, not an address in an
alternative linear address space)

It sounds like you're suggesting that an implementation may choose on a
per-section basis whether to use segmented addressing (because this assumes
an existing alternative linear addressing per x86) - and that some sections
/require/ the use of that linear addressing mode. Is that the idea?

But the segmented addressing section seems to say "addresses are specified
as offsets within a given segment rather than as locations within a single
flat address space" - sounds like it's talking about systems where there is
no flat address space, in which case the sections requiring a linear
addressing would present a problem when it comes to rendering them in DWARF.


>
> > 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.
>
> It's rarely beneficial to get into a hypothetical debate.  If you have
> no use case and are just postulating problems for which there is no
> evidence, there isn't much to be gained pursuing this.
>

The use case seems to be the original poster's question - and some
questions/uncertanties I had when reading the spec to try to understand it
to answer the question.

>     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.
>
> DWARF uses the same description for segmented addresses almost
> everywhere that an address is used.  This is for consistency.  The
> meaning is the same everywhere.
>

If the meaning is the same everywhere, then it seems strange that it's not
supported everywhere (such as debug_rnglist/ranges) - the meaning used in
2.12 seems to talk about a possible architecture that can only be addressed
via segmented addressing, without an alternative linear address space - yet
there are bits of DWARF where support for such an architecture seems to be
missing/incomplete.

I'd love to see some concrete examples of this sort of DWARF if you know of
any producer that uses this feature.

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