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

[David Blaikie via Dwarf-Discuss]

t/loclist (v5): includes segment selector size in the
> >  > header, but doesn't seem to use it - segment selection via
> > addresses in
> >  > the address pool (RLE/LLE_*x encodings) would allow fine-grained
> > segment
> >  > selection, but direct address forms don't seem to allow segment
> >  > selection ("This operand is the
> >  > 19 same size as used in DW_FORM_addr.")
> >  > debug_addr: segment_size in header, then list of {segment
> > selector, address}
> >  > debug_aranges: segment_size in header says, then the list contains
> >  > triples of {segment selector, start address, length}
> >  > debug_line: v5 encodes the address and segment selector size in
> the
> >  > header, but I'm not sure if/how it's used. The DW_LNE_set_address
> >  > operation says:
> >  > "The DW_LNE_set_address opcode takes a single relocatable address
> > as an
> >  > operand. The size of the operand is the size of an address on the
> > target
> >  > machine. It sets the address register to the value given by the
> >  > relocatable address and sets the op_index register to 0." -
> doesn't
> >  > sound like it's reading the segment selector there.
> >  >
> >  > So... I don't think DWARFv5 made anything worse - if anything it
> did
> >  > enable /a/ way to use fine grained segment selectors in range
> > lists and
> >  > location lists that doesn't appear, to me, to have been provided
> > before.
> >  > (it could be needed if you had some functions in some segment and
> > some
> >  > functions in another segment (which could be represented at the
> >  > subprogram DIE level - DW_AT_segment 1 on one DW_TAG_subprogram,
> >  > DW_AT_segment 2 on another DW_TAG_subprogram - but how would you
> >  > represent the DW_AT_ranges for this CU (in DWARFv4, or in DWARFv5
> >  > without using addrx encodings)? I don't know how, because I think
> >  > debug_ranges could describe one range list entry as being from one
> >  > segment, and another range list entry as being in another segment
> > - they
> >  > would all be in whatever segment was in DW_AT_segment on the CU)
> >  >
> >  > does that make sense? Have I missed something about how you could
> > use
> >  > segment selectors in a debug_loc, debug_ranges, or
> > loclist/rnglist that
> >  > isn't using an addrx encoding?
> >  >
> >  > On Wed, Jul 15, 2020 at 6:37 AM Robinson, Paul via Dwarf-Discuss
> >  >  > <mailto:dwarf-discuss@lists.dwarfstd.org>
> >  > <mailto:dwarf-discuss@lists.dwarfstd.org
> > <mailto:dwarf-discuss@lists.dwarfstd.org>>> wrote:
> >  >
> >  >
> >  >
> >  >  > -Original Message-
> >  >  > From: Dwarf-Discuss
> >  > <mailto:dwarf-discuss-boun...@lists.dwarfstd.org>
> >  > <mailto:dwarf-discuss-boun...@lists.dwarfstd.org
> > <mailto:dwarf-discuss-boun...@lists.dwarfstd.org>>> On Behalf
> >  >  > Of Xing GUO via Dwarf-Discuss
> >  >  > Sent: Tuesday, July 14, 2020 10:39 PM
> >  >  > To: dwarf-discuss@lists.dwarfstd.org
> > <mailto:dwarf-discuss@lists.dwarfstd.org>
> >  > <mailto:dwarf-discuss@lists.dwarfstd.org
> > <mailto:dwarf-discuss@lists.dwarfstd.org>>
> >  >  > Subject: [Dwarf-Discuss] Segment selectors for the range
> > list table.
> >  >  >
> >  >  > Hi there,
> >  >  >
> >  >  > The DWARFv5 spec mentioned that there might be segment
> > selectors in
> >  >  > the range list entries and when the segment_selector_size
> > is 0, the
> >  >  > segment selectors are omitted from the range list entries.
> >  > However, it
> >  >  > didn't mention how the segment selector should be encoded
> > when the
> >  >  > segment_selector_size isn't 0. Can anyone help me figure
> > it out?
> >  >  > Thanks a lot!
> >  >
> >  > Hi Xing,
> >  >
> >  > The segment selectors in the range list would be encoded the
> > same way
> >  > as they would be in the main .debug_info section.  Range
> > lists and
> >  > location lists are essentially extensions to .debug_info, for
> > cases
> >  > where the range or location cannot be represented by simple
> > DW_AT_*
> >  > attribute values.
> >  >
> >  > The specifics of encoding the segment selector would be
> > whatever is
> >  > appropriate to the target.  DWARF does not specify these
> details.
> >  >
> >  > Best Regards,
> >  > --paulr
> >  >
> >  >
> >  >  >
> >  >  > 7.28 (page 243)
> >  >  > The segment size is given by the segment_selector_size
> > field of the
> >  >  > header, and the address size is given by the address_size
> > field
> >  > of the
> >  >  > header. If the segment_selector_size field in the header
> > is zero, the
> >  >  > segment selector is omitted from the range list entries.
> >  >  >
> >  >  > --
> >  >  > Cheers,
> >  >  > Xing
> >
> >
> >
> > --
> > Michael Eager
> > ___
> > Dwarf-Discuss mailing list
> > Dwarf-Discuss@lists.dwarfstd.org
> > <mailto:Dwarf-Discuss@lists.dwarfstd.org>
> > http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
> >
>
> --
> Michael Eager
>
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

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

[David Blaikie via Dwarf-Discuss]

On Thu, Jul 16, 2020 at 6:35 PM Michael Eager  wrote:

> On 7/16/20 5:37 PM, David Blaikie wrote:
> >
> >
> > On Thu, Jul 16, 2020 at 4:25 PM Michael Eager 
> > 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?
>
> They refer to the same segmented addresses.
>
> There are not two discussions of segmented addresses in the DWARF spec.
>
> > 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.
>
> DW_AT_segment was intended to support addressing schemes like that used
> by x86 models.  The description is somewhat generalized, but that is the
> core of the concept.  If Intel used different terminology for their
> scheme, we would have used a different name.  In their usage, a
> segmented address maps (many-to-one) on a linear address space.
>
> Whether DW_AT_segment can be used to support a more general concept of
> disjoint address spaces is unclear.  AFAIK, no one has used it for this
> purpose.  DW_AT_address_class has been used, as I understand it, but I'm
> not familiar with these architectures.
>
> > 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.
>
> I've given you a concrete example: x86.
>

I was hoping for steps to produce DWARF that uses the feature from an
existing producer, to see how that producer interpreted the wording we're
discussing.

I'll see if I can make GCC do this, but I'm pretty unfamiliar with GCC for
non-host architectures - wouldn't mind any more specific tips if you have
them.

> 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)
>
> The majority (that is, all but one) of architectures use flat address
> spaces and have segment size = 0.
>
> The fact that DWARF supports an architecture which has a non-zero
> segment size should not be taken (as you appear to) to imply that all
> architectures must be somehow compelled to use non-zero segment size.
> The availability of a feature does not mandate its use.
>

Sorry, I didn't mean to imply that. I think what I meant to imply is that
it seems like if a producer is using segmented addresses in one part of
their output, they may want or need to do so in all sections.

But yeah, fully don't expect to need/use segmented addressing at all in
most/current producers.

> 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?
>
> An x86 memory model implementation might use segmented addressing in the
> .debug_info section, but not in the .debug_line section.
>
> Given the aliasing in x86 segmented memory, I'm not sure how it could be
> supported in the line table.
>

Yep, pretty confused about that - hopefully with a concrete example this'll
be more clear to me.

> 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.
>
> You are reading more into the text than is there.  Indeed, the example
> given does have a linear address space.
>
> If you want a concrete example, x86.   If you want to postulate an
> architecture which cannot be described in DWARF, have at it, but it's
> not a fruitful or illuminating discussion.
>
> > 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 

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

[David Blaikie via Dwarf-Discuss]

On Thu, Jul 16, 2020 at 4:25 PM Michael Eager  wrote:

> On 7/16/20 2:57 PM, David Blaikie wrote:
> >
> >
> > On Thu, Jul 16, 2020 at 2:05 PM Michael Eager  >
> > 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 

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

[Michael Eager via Dwarf-Discuss]

On 7/16/20 2:57 PM, David Blaikie wrote:



On Thu, Jul 16, 2020 at 2:05 PM Michael Eager 

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


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



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?


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.



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.



--
Michael Eager
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

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

[David Blaikie via Dwarf-Discuss]

On Thu, Jul 16, 2020 at 2:05 PM Michael Eager  wrote:

> On 7/16/20 1:36 PM, David Blaikie wrote:
> >
> >
> > On Thu, Jul 16, 2020 at 1:07 PM Michael Eager  > > 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 

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

[Michael Eager via Dwarf-Discuss]

On 7/16/20 1:36 PM, David Blaikie wrote:



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


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.


(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



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



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.

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.


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.

--
Michael Eager
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

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

[David Blaikie via Dwarf-Discuss]

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

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

[Michael Eager via Dwarf-Discuss]

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.



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.

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.

They are orthogonal concepts.  Compression techniques, like FORM_addrx, 
should not be used to describe architectural features.


--
Michael Eager
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

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

[Michael Eager via Dwarf-Discuss]

in the address pool can 
specify its own segment, but a producer could choose which way to go 
there. (presumably if the AT_segment is there, you should interpret the 
addrx high_pc relative to that segment - assuming debug_addr has no 
segment selector in it - or perhaps it should go the other way and 
ignore the local AT_segment and only rely on whatever segment is in 
debug_addr)


DW_FORM_addrx (and the .debug_addr section) were introduced in DWARF V5 
to allow compression of DW_FORM_addr addresses.  DW_AT_segment is 
intended to describe an (x86) address in the form that the processor 
uses.  The first is one of many different compression schemes in DWARF, 
the second is part of an architectural description.



On 7/15/20 4:31 PM, David Blaikie via Dwarf-Discuss wrote:
 > Looking at how segment selectors work:
 >
 > DW_AT_segment: Applies to a DIE subtree, including any ranges,
high/low
 > pc, locations, labels, etc
 > debug_range/loc (v4 and below): Doesn't seem to allow specifying
segment
 > variation - inherits from the segment given on the nearest parent
DIE
 > that refers to the entry
 > debug_rnglist/loclist (v5): includes segment selector size in the
 > header, but doesn't seem to use it - segment selection via
addresses in
 > the address pool (RLE/LLE_*x encodings) would allow fine-grained
segment
 > selection, but direct address forms don't seem to allow segment
 > selection ("This operand is the
 > 19 same size as used in DW_FORM_addr.")
 > debug_addr: segment_size in header, then list of {segment
selector, address}
 > debug_aranges: segment_size in header says, then the list contains
 > triples of {segment selector, start address, length}
 > debug_line: v5 encodes the address and segment selector size in the
 > header, but I'm not sure if/how it's used. The DW_LNE_set_address
 > operation says:
 > "The DW_LNE_set_address opcode takes a single relocatable address
as an
 > operand. The size of the operand is the size of an address on the
target
 > machine. It sets the address register to the value given by the
 > relocatable address and sets the op_index register to 0." - doesn't
 > sound like it's reading the segment selector there.
 >
 > So... I don't think DWARFv5 made anything worse - if anything it did
 > enable /a/ way to use fine grained segment selectors in range
lists and
 > location lists that doesn't appear, to me, to have been provided
before.
 > (it could be needed if you had some functions in some segment and
some
 > functions in another segment (which could be represented at the
 > subprogram DIE level - DW_AT_segment 1 on one DW_TAG_subprogram,
 > DW_AT_segment 2 on another DW_TAG_subprogram - but how would you
 > represent the DW_AT_ranges for this CU (in DWARFv4, or in DWARFv5
 > without using addrx encodings)? I don't know how, because I think
 > debug_ranges could describe one range list entry as being from one
 > segment, and another range list entry as being in another segment
- they
 > would all be in whatever segment was in DW_AT_segment on the CU)
 >
 > does that make sense? Have I missed something about how you could
use
 > segment selectors in a debug_loc, debug_ranges, or
loclist/rnglist that
 > isn't using an addrx encoding?
 >
 > On Wed, Jul 15, 2020 at 6:37 AM Robinson, Paul via Dwarf-Discuss
 > mailto:dwarf-discuss@lists.dwarfstd.org>
 > <mailto:dwarf-discuss@lists.dwarfstd.org
<mailto:dwarf-discuss@lists.dwarfstd.org>>> wrote:
 >
 >
 >
 >      > -Original Message-
 >      > From: Dwarf-Discuss
mailto:dwarf-discuss-boun...@lists.dwarfstd.org>
 >     <mailto:dwarf-discuss-boun...@lists.dwarfstd.org
<mailto:dwarf-discuss-boun...@lists.dwarfstd.org>>> On Behalf
 >      > Of Xing GUO via Dwarf-Discuss
 >      > Sent: Tuesday, July 14, 2020 10:39 PM
 >      > To: dwarf-discuss@lists.dwarfstd.org
<mailto:dwarf-discuss@lists.dwarfstd.org>
 >     <mailto:dwarf-discuss@lists.dwarfstd.org
<mailto:dwarf-discuss@lists.dwarfstd.org>>
 >      > Subject: [Dwarf-Discuss] Segment selectors for the range
list table.
 >      >
 >      > Hi there,
 >      >
 >      > The DWARFv5 spec mentioned that there might be segment
selectors in
 >      > the range list entries and when the segment_selector_size
is 0, the
 >      > segment selectors are omitted from the range list entries.
 >     However, it
 >      > didn't mention how the seg

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

[David Blaikie via Dwarf-Discuss]

On Wed, Jul 15, 2020 at 8:00 PM Xing GUO  wrote:

> Hi David,
>
> On 7/16/20, David Blaikie  wrote:
> > Looking at how segment selectors work:
> >
> > DW_AT_segment: Applies to a DIE subtree, including any ranges, high/low
> pc,
> > locations, labels, etc
> > debug_range/loc (v4 and below): Doesn't seem to allow specifying segment
> > variation - inherits from the segment given on the nearest parent DIE
> that
> > refers to the entry
> > debug_rnglist/loclist (v5): includes segment selector size in the header,
> > but doesn't seem to use it - segment selection via addresses in the
> address
> > pool (RLE/LLE_*x encodings) would allow fine-grained segment selection,
> but
> > direct address forms don't seem to allow segment selection ("This operand
> > is the
> > 19 same size as used in DW_FORM_addr.")
>
> Thanks for your explanation.
>

Note: there seems to be some disagreement with my understanding - and I
haven't been around these parts nearly as long as some other folk - so
there's a fair chance I'm wrong/misunderstanding/misreading things.


> So, If we want to use segmented addresses in the debug_rnglist or
> debug_loclist table, we should use encodings like: startx_endx,
> startx_length, etc., to index the {segment/address} pairs in the
> address table of the .debug_addr section rather than the direct
> address forms like: start_end, start_length, etc., right?
>

That's /my/ understanding. (side note: imho: it's good to use the addrx
forms anyway - since you can reduce relocations (& thus object size) that
way - try some experiments with Clang's DWARFv5 support to see how I
implemented it there/how I think it should be done (admittedly I have a
bias towards reducing object size especially, since that's a particular
issue for my customers))


> Besides, the segment_selector_size is just an indicator that tells us
> if the current debug_rnglist/debug_loclist table is using segmented
> address and it should have no effects on parsing the encoding and
> operands (e.g., {DW_RLE_startx_endx, operands0, operands1},
> {DW_RLE_start_end, operands0, operands1}) in the entries.
>

None that I can see - which seems suspicious to me. (similarly in
debug_line - there's a segment_selector_size in the header, but no use that
I know of in the actual parsing of the implementation... )


>
> > debug_addr: segment_size in header, then list of {segment selector,
> > address}
> > debug_aranges: segment_size in header says, then the list contains
> triples
> > of {segment selector, start address, length}
> > debug_line: v5 encodes the address and segment selector size in the
> header,
> > but I'm not sure if/how it's used. The DW_LNE_set_address operation says:
> > "The DW_LNE_set_address opcode takes a single relocatable address as an
> > operand. The size of the operand is the size of an address on the target
> > machine. It sets the address register to the value given by the
> relocatable
> > address and sets the op_index register to 0." - doesn't sound like it's
> > reading the segment selector there.
> >
> > So... I don't think DWARFv5 made anything worse - if anything it did
> enable
> > /a/ way to use fine grained segment selectors in range lists and location
> > lists that doesn't appear, to me, to have been provided before. (it could
> > be needed if you had some functions in some segment and some functions in
> > another segment (which could be represented at the subprogram DIE level -
> > DW_AT_segment 1 on one DW_TAG_subprogram, DW_AT_segment 2 on another
> > DW_TAG_subprogram - but how would you represent the DW_AT_ranges for this
> > CU (in DWARFv4, or in DWARFv5 without using addrx encodings)? I don't
> know
> > how, because I think debug_ranges could describe one range list entry as
> > being from one segment, and another range list entry as being in another
> > segment - they would all be in whatever segment was in DW_AT_segment on
> the
> > CU)
> >
> > does that make sense? Have I missed something about how you could use
> > segment selectors in a debug_loc, debug_ranges, or loclist/rnglist that
> > isn't using an addrx encoding?
> >
> > On Wed, Jul 15, 2020 at 6:37 AM Robinson, Paul via Dwarf-Discuss <
> > dwarf-discuss@lists.dwarfstd.org> wrote:
> >
> >>
> >>
> >> > -Original Message-
> >> > From: Dwarf-Discuss  On
> >> > Behalf
> >> > Of Xing GUO via Dwarf-Discuss
> >> > Sent: Tuesday, July 14, 2020 10:39 PM
> >> > To: dwarf-discuss@lists.dwarfstd.org
> >> > Subject: [Dwarf-Discuss] Segment selectors for the range

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

[David Blaikie via Dwarf-Discuss]

> > debug_line: v5 encodes the address and segment selector size in the
> > header, but I'm not sure if/how it's used. The DW_LNE_set_address
> > operation says:
> > "The DW_LNE_set_address opcode takes a single relocatable address as an
> > operand. The size of the operand is the size of an address on the target
> > machine. It sets the address register to the value given by the
> > relocatable address and sets the op_index register to 0." - doesn't
> > sound like it's reading the segment selector there.
> >
> > So... I don't think DWARFv5 made anything worse - if anything it did
> > enable /a/ way to use fine grained segment selectors in range lists and
> > location lists that doesn't appear, to me, to have been provided before.
> > (it could be needed if you had some functions in some segment and some
> > functions in another segment (which could be represented at the
> > subprogram DIE level - DW_AT_segment 1 on one DW_TAG_subprogram,
> > DW_AT_segment 2 on another DW_TAG_subprogram - but how would you
> > represent the DW_AT_ranges for this CU (in DWARFv4, or in DWARFv5
> > without using addrx encodings)? I don't know how, because I think
> > debug_ranges could describe one range list entry as being from one
> > segment, and another range list entry as being in another segment - they
> > would all be in whatever segment was in DW_AT_segment on the CU)
> >
> > does that make sense? Have I missed something about how you could use
> > segment selectors in a debug_loc, debug_ranges, or loclist/rnglist that
> > isn't using an addrx encoding?
> >
> > On Wed, Jul 15, 2020 at 6:37 AM Robinson, Paul via Dwarf-Discuss
> >  > <mailto:dwarf-discuss@lists.dwarfstd.org>> wrote:
> >
> >
> >
> >  > -Original Message-
> >  > From: Dwarf-Discuss  > <mailto:dwarf-discuss-boun...@lists.dwarfstd.org>> On Behalf
> >  > Of Xing GUO via Dwarf-Discuss
> >  > Sent: Tuesday, July 14, 2020 10:39 PM
> >  > To: dwarf-discuss@lists.dwarfstd.org
> > <mailto:dwarf-discuss@lists.dwarfstd.org>
> >  > Subject: [Dwarf-Discuss] Segment selectors for the range list
> table.
> >  >
> >  > Hi there,
> >  >
> >  > The DWARFv5 spec mentioned that there might be segment selectors
> in
> >  > the range list entries and when the segment_selector_size is 0,
> the
> >  > segment selectors are omitted from the range list entries.
> > However, it
> >  > didn't mention how the segment selector should be encoded when the
> >  > segment_selector_size isn't 0. Can anyone help me figure it out?
> >  > Thanks a lot!
> >
> > Hi Xing,
> >
> > The segment selectors in the range list would be encoded the same way
> > as they would be in the main .debug_info section.  Range lists and
> > location lists are essentially extensions to .debug_info, for cases
> > where the range or location cannot be represented by simple DW_AT_*
> > attribute values.
> >
> > The specifics of encoding the segment selector would be whatever is
> > appropriate to the target.  DWARF does not specify these details.
> >
> > Best Regards,
> > --paulr
> >
> >
> >  >
> >  > 7.28 (page 243)
> >  > The segment size is given by the segment_selector_size field of
> the
> >  > header, and the address size is given by the address_size field
> > of the
> >  > header. If the segment_selector_size field in the header is zero,
> the
> >  > segment selector is omitted from the range list entries.
> >  >
> >  > --
> >  > Cheers,
> >  > Xing
>
>
>
> --
> Michael Eager
> ___
> Dwarf-Discuss mailing list
> Dwarf-Discuss@lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

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

[Xing GUO via Dwarf-Discuss]

Hi David,

On 7/16/20, David Blaikie  wrote:
> Looking at how segment selectors work:
>
> DW_AT_segment: Applies to a DIE subtree, including any ranges, high/low pc,
> locations, labels, etc
> debug_range/loc (v4 and below): Doesn't seem to allow specifying segment
> variation - inherits from the segment given on the nearest parent DIE that
> refers to the entry
> debug_rnglist/loclist (v5): includes segment selector size in the header,
> but doesn't seem to use it - segment selection via addresses in the address
> pool (RLE/LLE_*x encodings) would allow fine-grained segment selection, but
> direct address forms don't seem to allow segment selection ("This operand
> is the
> 19 same size as used in DW_FORM_addr.")

Thanks for your explanation.

So, If we want to use segmented addresses in the debug_rnglist or
debug_loclist table, we should use encodings like: startx_endx,
startx_length, etc., to index the {segment/address} pairs in the
address table of the .debug_addr section rather than the direct
address forms like: start_end, start_length, etc., right?

Besides, the segment_selector_size is just an indicator that tells us
if the current debug_rnglist/debug_loclist table is using segmented
address and it should have no effects on parsing the encoding and
operands (e.g., {DW_RLE_startx_endx, operands0, operands1},
{DW_RLE_start_end, operands0, operands1}) in the entries.

> debug_addr: segment_size in header, then list of {segment selector,
> address}
> debug_aranges: segment_size in header says, then the list contains triples
> of {segment selector, start address, length}
> debug_line: v5 encodes the address and segment selector size in the header,
> but I'm not sure if/how it's used. The DW_LNE_set_address operation says:
> "The DW_LNE_set_address opcode takes a single relocatable address as an
> operand. The size of the operand is the size of an address on the target
> machine. It sets the address register to the value given by the relocatable
> address and sets the op_index register to 0." - doesn't sound like it's
> reading the segment selector there.
>
> So... I don't think DWARFv5 made anything worse - if anything it did enable
> /a/ way to use fine grained segment selectors in range lists and location
> lists that doesn't appear, to me, to have been provided before. (it could
> be needed if you had some functions in some segment and some functions in
> another segment (which could be represented at the subprogram DIE level -
> DW_AT_segment 1 on one DW_TAG_subprogram, DW_AT_segment 2 on another
> DW_TAG_subprogram - but how would you represent the DW_AT_ranges for this
> CU (in DWARFv4, or in DWARFv5 without using addrx encodings)? I don't know
> how, because I think debug_ranges could describe one range list entry as
> being from one segment, and another range list entry as being in another
> segment - they would all be in whatever segment was in DW_AT_segment on the
> CU)
>
> does that make sense? Have I missed something about how you could use
> segment selectors in a debug_loc, debug_ranges, or loclist/rnglist that
> isn't using an addrx encoding?
>
> On Wed, Jul 15, 2020 at 6:37 AM Robinson, Paul via Dwarf-Discuss <
> dwarf-discuss@lists.dwarfstd.org> wrote:
>
>>
>>
>> > -Original Message-
>> > From: Dwarf-Discuss  On
>> > Behalf
>> > Of Xing GUO via Dwarf-Discuss
>> > Sent: Tuesday, July 14, 2020 10:39 PM
>> > To: dwarf-discuss@lists.dwarfstd.org
>> > Subject: [Dwarf-Discuss] Segment selectors for the range list table.
>> >
>> > Hi there,
>> >
>> > The DWARFv5 spec mentioned that there might be segment selectors in
>> > the range list entries and when the segment_selector_size is 0, the
>> > segment selectors are omitted from the range list entries. However, it
>> > didn't mention how the segment selector should be encoded when the
>> > segment_selector_size isn't 0. Can anyone help me figure it out?
>> > Thanks a lot!
>>
>> Hi Xing,
>>
>> The segment selectors in the range list would be encoded the same way
>> as they would be in the main .debug_info section.  Range lists and
>> location lists are essentially extensions to .debug_info, for cases
>> where the range or location cannot be represented by simple DW_AT_*
>> attribute values.
>>
>> The specifics of encoding the segment selector would be whatever is
>> appropriate to the target.  DWARF does not specify these details.
>>
>> Best Regards,
>> --paulr
>>
>>
>> >
>> > 7.28 (page 243)
>> > The segment size is given by the segment_selector_size field of the
>> > header, and the address siz

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

[Xing GUO via Dwarf-Discuss]

Hi there,

The DWARFv5 spec mentioned that there might be segment selectors in
the range list entries and when the segment_selector_size is 0, the
segment selectors are omitted from the range list entries. However, it
didn't mention how the segment selector should be encoded when the
segment_selector_size isn't 0. Can anyone help me figure it out?
Thanks a lot!

7.28 (page 243)
The segment size is given by the segment_selector_size field of the
header, and the address size is given by the address_size field of the
header. If the segment_selector_size field in the header is zero, the
segment selector is omitted from the range list entries.

-- 
Cheers,
Xing
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org