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

[David Blaikie]

On Thu, Jul 16, 2020 at 1:07 PM Michael Eager <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?

>     AFAIK, all addresses can be segmented addresses, except in the line
> >     table where it isn't needed.
> >
> >     Perhaps we should have (long ago) required flat/linear addresses for
> >     x86
> >     instead of segmented addresses.
> >
> >
> > What's the line table's segment_selector_size (in the DWARFv5 header)
> > for? (this sort of agrees and disagrees with you - it's there, but it's
> > not used in any part of the debug_line format that I can see)
>
> It may be there for consistency across all headers.
>

Seems a bit quirky at best, given the value is unused.
(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))


> > 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)

2.12 Segmented Addresses:
"The description evaluates to the segment selector of the item being
described."

6.1.2 Lookup by Address: (this one it sounds like you're saying is meant to
refer to the same kind of segmenting as 2.12? To allow lookup by address
across data and code, for instance, that would be in different segments?)
"address_size (ubyte) The size of an address in bytes on the target
architecture. For segmented addressing, this is the size of the offset
portion of the address."
"segment_selector_size (ubyte): The size of a segment selector in bytes on
the target architecture. If the target system uses a flat address space,
this value is 0."

6.2.4: The Line Number Program Header
"address_size (ubyte) A 1-byte unsigned integer containing the size in
bytes of an address (or offset portion of an address for segmented
addressing) on the target system"
"segment_selector_size (ubyte) A 1-byte unsigned integer containing the
size in bytes of a segment selector on the target system.
"*The segment_selector_size field is new in DWARF Version 5. It is needed
in combination with the address_size field to accurately characterize the
address representation on the target system.*"
(but doesn't seem to actually use the segment selector size anywhere? so it
assumes some known constant/implementation-defined segment?)

6.4.1 Structure of Call Frame Information
"segment_selector_size (ubyte) The size of a segment selector in this CIE
and any FDEs that use it, in bytes"
"initial_location (segment selector and target address) 2 The address of
the first location associated with this table entry. If the 3
segment_selector_size field of this FDE?s CIE is non-zero, the initial 4
location is preceded by a segment selector of the given length."
6.4.2.1: "If the segment_selector_size field of this FDE?s CIE is non-zero,
8 the initial location is preceded by a segment selector of the given
length."

7.5.1.1 Full and Partial Compile Unit Headers:
"address_size (ubyte) A 1-byte unsigned integer representing the size in
bytes of an address on the target architecture. If the system uses
segmented addressing, this value represents the size of the offset portion
of an address."

7.27 Address Table
"address_size (ubyte) A 1-byte unsigned integer containing the size in
bytes of an address (or the offset portion of an address for segmented
addressing) on the target system."
"segment_selector_size (ubyte) A 1-byte unsigned integer containing the
size in bytes of a segment selector on the target system."
(/does/ use segment_selector_size: "This header is followed by a series of
segment/address pairs.")

7.28 Range List Table
"address_size (ubyte) A 1-byte unsigned integer containing the size in
bytes of an address (or the offset portion of an address for segmented
addressing) on the target system."
"segment_selector_size (ubyte) A 1-byte unsigned integer containing the
size in bytes of a segment selector on the target system"
(doesn't seem to use segment_selector_size at all)

7.29 Location List Table
"address_size (ubyte) A 1-byte unsigned integer containing the size in
bytes of an address (or the 22 offset portion of an address for segmented
addressing) on the target system."
"segment_selector_size (ubyte) A 1-byte unsigned integer containing the
size in bytes of a segment selector on the target system."
(doesn't seem to use segment_selector_size at all)


> 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.

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)

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