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

[David Blaikie via Dwarf-Discuss]

Anyone know of any existing DWARF producers that use segmented addressing?
Might be interesting to see how they're using the features.

On Thu, Jul 16, 2020 at 9:30 AM Michael Eager  wrote:

> On 7/15/20 9:49 PM, David Blaikie wrote:
> >
> >
> > On Wed, Jul 15, 2020 at 7:07 PM Michael Eager via Dwarf-Discuss
> >  > > wrote:
> >
> > Segmented addresses have been in the DWARF specification since
> > Version 2
> >and AFAIK have not been changed since that time.  DWARF V5 did
> > not add
> > any functionality to segmented addresses that was not present in
> DWARF
> > V2/3.  At least, there was no intention to do so.  Segmented
> addresses
> > are described in Section 2.12.
> >
> > A segmented address maps into a linear address in a
> processor-specific
> > fashion.
> >
> >
> > That seems at odds with the non-normative text of 2.12 "In some systems,
> > addresses are specified as offsets within a given segment rather than as
> > locations within a single flat address space."
>
> That means that an x86 address could be represented as offset 0x1234 in
> segment 0x, which would translate to 0x0+0x1234=0x45674.  Note
> that x86 permits aliases, so that offset 0x0124 in segment 0x4555 is the
> same address.
>
> DWARF sometimes uses wording which is intended to generalize a concept.
> Conceivably, another architecture could use the same DWARF attribute in
> a similar way.  That's why the non-normative text says "some systems"
> rather than specifically referencing x86.  But we do have that as the
> only example listed in the table.
>
> > And also would be confusing to me - if there is a contiguous linear
> > address space, why would DWARF need to specify the use of a segment
> > selector, and why do some references to addresses allow the inclusion of
> > a segment selector and some don't? Why not just always use the
> > non-segmented address description for DWARF?
>
> So that a compiler can generate segment address values and offsets
> independently.  An x86 code generator may not know what segment it is
> generating code in.
>

But parts of the format (such as debug_ranges - sort of, and debug_line)
assume the DWARF producer does know the absolute address. It seems
inconsistent to me.

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


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

What I'm confused by is how you can use segmented addressing on a
per-DIE-subtree basis (eg: one subprogram can specify one segment, and
another subprogram can specify a different segment - the spec seems to be
pretty clear that this is intentionally supported (says that it applies to
high_pc/low_pc/ranges, and that it delegates to the nearest parent DIE's
DW_AT_segment)) but it doesn't seem like you can have a range list (in v4
or v5 (except via the addrx encodings)) that can have different segments
for different subranges within a single range list. So how would you
describe the ranges of a CU that had subprograms in distinct segments? And
if you can't describe that - then why does the spec go out of its way to
explicitly allow it with the wording about segment overrides, etc.


>
> > & I don't find any mention of this idea that some addresses are absolute
> > and some are segment-relative in 2.12 - it does say that "If none of the
> > entries in the chain of parents for this entry back to its containing
> > compilation unit entry have DW_AT_segment attributes, then the entry is
> > assumed to exist within a flat address space." - as though a flat (I
> > assume this is synonymous with "linear"?) address space is distinct from
> > the segmented address space being discussed otherwise?
>
> Flat address space == linear address space.
>
>  From a certain perspective, x86 memory space is broken up into 65K
> 16-byte segments mapped onto a 256K linear address range.

> AFAIK, only the Intel 8086 and descendants have this
> > functionality.  (It's a many to one mapping in the 8086
> implementation,
> > but that's a problem for a bygone era.)  There's a reference to i386
> > memory models in Table 2.7.
> >
> > DWARF assumes a linear address space.  A segmented address maps to a
> > specific address in this linear address space.  The 

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] modeling different address spaces

[David Blaikie via Dwarf-Discuss]

On Thu, Jul 16, 2020 at 12:55 PM Michael Eager  wrote:

> On 7/16/20 11:51 AM, David Blaikie wrote:
> >
> >
> > On Thu, Jul 16, 2020 at 11:41 AM Robinson, Paul via Dwarf-Discuss
> > The example that most often comes up is Harvard architectures.  As it
> > happens, I think it's nearly always obvious from context whether a
> given
> > address is data-segment or code-segment.  The only time it's not,
> > that I'm
> > aware of, is in the .debug_aranges section, where addresses are
> > associated
> > with compile-units without any indication of whether they are code
> > or data
> > addresses.  I've heard arguments that .debug_aranges should only
> > have code
> > addresses in it, but I don't think that's what the spec says.
> >
> >
> > Curious - the spec doesn't seem to read that way to me - and if that
> > were its goal, it seems like DW_AT_segment wouldn't really be needed.
>
> As Paul said, DW_AT_segment is not generally needed to describe a
> Harvard architecture.
>
> > DW_AT_locations would always be data, DW_AT_high/low/ranges would always
> > be code, etc? The spec... specifically says DW_AT_segment applies to
> > high/low/ranges, and describes a parent-DIE delegation scheme that seems
> > to suggest that some DIEs could have one segment, and others could have
> > a different segment - but no way for ranges to have different segments
> > in different parts of the same range list, which seems to be at odds
> > with the ability to vary segment across a DIE tree - you couldn't put a
> > ranges at the top of such a variegated tree...
>
> On some (many?) architectures, data and code may be interspersed, for
> example, to place constant data with the executable text.
>
> DIEs can have different DW_AT_segments.
>
> Entries in .debug_aranges have segment, offset, and length.
>
> What is the use case for having multiple segments in a range list?
>

The same as the use case for varying the segment per high_pc, I'd have
thought - if code is in different segments. But if you're suggesting the
only valid use of DW_AT_segment is to always have it have the same value on
any DIE with ranges/low/high pc, and always the same (but possibly a
distinct value) for DW_AT_location-having DIEs, fair enough. The spec
doesn't seem to say that, though. It suggests it could vary more than that?

Guess for things like the original poster's case (though, like Paul, I've
not read AMD's proposal here) - GPU code with a separate address space from
CPU code, for instance.


> > (& yeah, the arange situation crossed my mind too - on both counts you
> > noted (that it needs it, but that it may not - because some
> > interpretations suggest it should only contain code addresses anyway))
>
> As Paul mentioned, that's not what the spec says.
>
> > & not sure how any of this resolves the "but debug_addr has segment
> > selectors"
> >
> > nor "what's the point of segment selector size in debug_rnglists,
> > debug_loclists, and debug_line" - none of those sections seem to contain
> > segment selectors, so why do their headers describe the size of such a
> > thing?
>
> Location lists contain segment, offset, and length.
>

I don't see any mention of segment in 2.6.2 - or do you mean base address
selection entries? Yeah, you could use those (& can use them even in an
unsegmented situation) & can use those in debug_ranges too. So, again, if
the notion is that everything's really in a contiguous address space &
segment selectors are a convenience - that lines up here.

loc/range and loclist/rnglist seem to use the same encoding for their
address ranges (loc/loclist just have the extra location tacked on after
the address range description) - as far as I've read.


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

Re: [Dwarf-Discuss] modeling different address spaces

[Michael Eager via Dwarf-Discuss]

On 7/16/20 11:51 AM, David Blaikie wrote:



On Thu, Jul 16, 2020 at 11:41 AM Robinson, Paul via Dwarf-Discuss 
The example that most often comes up is Harvard architectures.  As it

happens, I think it's nearly always obvious from context whether a given
address is data-segment or code-segment.  The only time it's not,
that I'm
aware of, is in the .debug_aranges section, where addresses are
associated
with compile-units without any indication of whether they are code
or data
addresses.  I've heard arguments that .debug_aranges should only
have code
addresses in it, but I don't think that's what the spec says.


Curious - the spec doesn't seem to read that way to me - and if that 
were its goal, it seems like DW_AT_segment wouldn't really be needed. 


As Paul said, DW_AT_segment is not generally needed to describe a 
Harvard architecture.


DW_AT_locations would always be data, DW_AT_high/low/ranges would always 
be code, etc? The spec... specifically says DW_AT_segment applies to 
high/low/ranges, and describes a parent-DIE delegation scheme that seems 
to suggest that some DIEs could have one segment, and others could have 
a different segment - but no way for ranges to have different segments 
in different parts of the same range list, which seems to be at odds 
with the ability to vary segment across a DIE tree - you couldn't put a 
ranges at the top of such a variegated tree...


On some (many?) architectures, data and code may be interspersed, for 
example, to place constant data with the executable text.


DIEs can have different DW_AT_segments.

Entries in .debug_aranges have segment, offset, and length.

What is the use case for having multiple segments in a range list?

(& yeah, the arange situation crossed my mind too - on both counts you 
noted (that it needs it, but that it may not - because some 
interpretations suggest it should only contain code addresses anyway))


As Paul mentioned, that's not what the spec says.

& not sure how any of this resolves the "but debug_addr has segment 
selectors"


nor "what's the point of segment selector size in debug_rnglists, 
debug_loclists, and debug_line" - none of those sections seem to contain 
segment selectors, so why do their headers describe the size of such a 
thing?


Location lists contain segment, offset, and length.

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

Re: [Dwarf-Discuss] modeling different address spaces

[David Blaikie via Dwarf-Discuss]

On Thu, Jul 16, 2020 at 11:41 AM Robinson, Paul via Dwarf-Discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:

> (resending, this time without dropping the list from the cc: grump grump)
>
> > -Original Message-
> > From: Dwarf-Discuss  On Behalf
> > Of Michael Eager via Dwarf-Discuss
> > Sent: Thursday, July 16, 2020 2:12 PM
> > To: todd.al...@concurrent-rt.com; Metzger, Markus T
> > 
> > Cc: dwarf-discuss@lists.dwarfstd.org
> > Subject: Re: [Dwarf-Discuss] modeling different address spaces
> >
> > On 7/16/20 10:06 AM, Todd Allen via Dwarf-Discuss wrote:
> > > Markus, Michael, David, Xing,
> > >
> > > I always assumed that the segment support in DWARF was meant to be more
> > general,
> > > and support architectures where there was no single flat memory, and so
> > the
> > > segments were necessary for memory accesses.  I personally have not
> > dealt with
> > > any architectures where DW_AT_segment came into play, though.
> >
> > It is phrased in a way to make it less architecturally specific.  That's
> > in keeping with our desire to prevent DWARF from including architecture
> > specific specifications.  For example, we don't want to say "on ARM do
> > this" but on "MIPS do that".  DWARF doesn't specify how the translation
> > from segmented to linear addresses is done.
>
> The example that most often comes up is Harvard architectures.  As it
> happens, I think it's nearly always obvious from context whether a given
> address is data-segment or code-segment.  The only time it's not, that I'm
> aware of, is in the .debug_aranges section, where addresses are associated
> with compile-units without any indication of whether they are code or data
> addresses.  I've heard arguments that .debug_aranges should only have code
> addresses in it, but I don't think that's what the spec says.
>

Curious - the spec doesn't seem to read that way to me - and if that were
its goal, it seems like DW_AT_segment wouldn't really be needed.
DW_AT_locations would always be data, DW_AT_high/low/ranges would always be
code, etc? The spec... specifically says DW_AT_segment applies to
high/low/ranges, and describes a parent-DIE delegation scheme that seems to
suggest that some DIEs could have one segment, and others could have a
different segment - but no way for ranges to have different segments in
different parts of the same range list, which seems to be at odds with the
ability to vary segment across a DIE tree - you couldn't put a ranges at
the top of such a variegated tree...

(& yeah, the arange situation crossed my mind too - on both counts you
noted (that it needs it, but that it may not - because some interpretations
suggest it should only contain code addresses anyway))

& not sure how any of this resolves the "but debug_addr has segment
selectors"

nor "what's the point of segment selector size in debug_rnglists,
debug_loclists, and debug_line" - none of those sections seem to contain
segment selectors, so why do their headers describe the size of such a
thing?


> --paulr
>
> ___
> 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] modeling different address spaces

[Robinson, Paul via Dwarf-Discuss]

(resending, this time without dropping the list from the cc: grump grump)

> -Original Message-
> From: Dwarf-Discuss  On Behalf
> Of Michael Eager via Dwarf-Discuss
> Sent: Thursday, July 16, 2020 2:12 PM
> To: todd.al...@concurrent-rt.com; Metzger, Markus T
> 
> Cc: dwarf-discuss@lists.dwarfstd.org
> Subject: Re: [Dwarf-Discuss] modeling different address spaces
> 
> On 7/16/20 10:06 AM, Todd Allen via Dwarf-Discuss wrote:
> > Markus, Michael, David, Xing,
> >
> > I always assumed that the segment support in DWARF was meant to be more
> general,
> > and support architectures where there was no single flat memory, and so
> the
> > segments were necessary for memory accesses.  I personally have not
> dealt with
> > any architectures where DW_AT_segment came into play, though.
> 
> It is phrased in a way to make it less architecturally specific.  That's
> in keeping with our desire to prevent DWARF from including architecture
> specific specifications.  For example, we don't want to say "on ARM do
> this" but on "MIPS do that".  DWARF doesn't specify how the translation
> from segmented to linear addresses is done.

The example that most often comes up is Harvard architectures.  As it
happens, I think it's nearly always obvious from context whether a given
address is data-segment or code-segment.  The only time it's not, that I'm
aware of, is in the .debug_aranges section, where addresses are associated
with compile-units without any indication of whether they are code or data
addresses.  I've heard arguments that .debug_aranges should only have code
addresses in it, but I don't think that's what the spec says.
--paulr

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

Re: [Dwarf-Discuss] modeling different address spaces

[Robinson, Paul via Dwarf-Discuss]

> -Original Message-
> From: Dwarf-Discuss  On Behalf
> Of Michael Eager via Dwarf-Discuss
> Sent: Thursday, July 16, 2020 2:22 PM
> To: John DelSignore ; todd.allen@concurrent-
> rt.com; Metzger, Markus T 
> Cc: dwarf-discuss@lists.dwarfstd.org; Tye, Tony 
> Subject: Re: [Dwarf-Discuss] modeling different address spaces
> 
> On 7/16/20 10:26 AM, John DelSignore via Dwarf-Discuss wrote:
> > FYI, Tony Tye and his team at AMD created a DWARF Proposal for
> heterogeneous debugging, which is generally useful but required to debug
> optimized code for GPUs. It directly addresses the issue of how to model
> different address spaces and makes location descriptions first-class
> objects that can be push onto the evaluation stack.
> >
> >
> https://urldefense.com/v3/__https://llvm.org/docs/AMDGPUDwarfProposalForHe
> terogeneousDebugging.html__;!!JmoZiZGBv3RvKRSx!rcLFM5tXmxFw3UnRNhyWapnfPy9
> w2jREY_Id2g3BwR_gCVTPgXEAsLA2NKIn2q-qcA$
> >
> > AFAIK, these changes will be made to LLVM and there is interest in
> adding to the DWARF standard eventually.
> 
> As mentioned in the past, I would be pleased to see proposals submitted
> for these changes.
> 
> I would like to avoid the situation where we have an informal proposal
> lacking specific changes to the DWARF standard, matched with an
> implementation which claims to match the proposal.  That's the opposite
> of standardization.

I think the idea was, it would be implementation experience, which will
inform the proposal.  I've had "review this work" on my to-do list for
an embarrassingly long time now.  The initial problem is that it's a
huge chunk of stuff and is a big time investment to look at.
--paulr

> 
> --
> Michael Eager
> ___
> Dwarf-Discuss mailing list
> Dwarf-Discuss@lists.dwarfstd.org
> https://urldefense.com/v3/__http://lists.dwarfstd.org/listinfo.cgi/dwarf-
> discuss-
> dwarfstd.org__;!!JmoZiZGBv3RvKRSx!rcLFM5tXmxFw3UnRNhyWapnfPy9w2jREY_Id2g3B
> wR_gCVTPgXEAsLA2NKK8z2h0fg$
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] modeling different address spaces

[Michael Eager via Dwarf-Discuss]

On 7/16/20 10:26 AM, John DelSignore via Dwarf-Discuss wrote:

FYI, Tony Tye and his team at AMD created a DWARF Proposal for heterogeneous 
debugging, which is generally useful but required to debug optimized code for 
GPUs. It directly addresses the issue of how to model different address spaces 
and makes location descriptions first-class objects that can be push onto the 
evaluation stack.

https://llvm.org/docs/AMDGPUDwarfProposalForHeterogeneousDebugging.html

AFAIK, these changes will be made to LLVM and there is interest in adding to 
the DWARF standard eventually.


As mentioned in the past, I would be pleased to see proposals submitted 
for these changes.


I would like to avoid the situation where we have an informal proposal 
lacking specific changes to the DWARF standard, matched with an 
implementation which claims to match the proposal.  That's the opposite 
of standardization.


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

Re: [Dwarf-Discuss] modeling different address spaces

[Michael Eager via Dwarf-Discuss]

On 7/16/20 10:06 AM, Todd Allen via Dwarf-Discuss wrote:

Markus, Michael, David, Xing,

I always assumed that the segment support in DWARF was meant to be more general,
and support architectures where there was no single flat memory, and so the
segments were necessary for memory accesses.  I personally have not dealt with
any architectures where DW_AT_segment came into play, though.


It is phrased in a way to make it less architecturally specific.  That's 
in keeping with our desire to prevent DWARF from including architecture 
specific specifications.  For example, we don't want to say "on ARM do 
this" but on "MIPS do that".  DWARF doesn't specify how the translation 
from segmented to linear addresses is done.



Certainly x86 does not fall into that "truly distinct segments" category, at
least not in modern times.  The segment registers there (fs & gs, for example)
are an indirect way of specifying a base address within the flat address space.
They usually end up being used for thread-specific data structures where each
thread has a different segment selector which implies a different base address.
And it requires a syscall to interact with the base addresses, at least on
Linux.  The other segment registers (cs, ds, ss) are set-and-forget by the OS
typically.


As soon as you mention segment registers, you move from the static 
description of the memory image to the dynamic description of the 
execution.  DW_AT_segment is a static description of memory layout.  The 
computations in a DWARF expression (which may reference a segment 
register) are only relevant when looking at an executing program (or a 
memory dump) and you have a PC context.


The Intel terminology describing the static memory addressing as 
segments with the dynamic segment registers leads to this confusion.



The CUDA architecture is an interesting case.  It doesn't use DW_AT_segment at
all.  But it does use the DW_AT_address_class attribute to specify CUDA segments
(e.g. Global, Local, Shared, among many others) for variables and/or types.  So
it's fairly fine-grained.  You can, for example, have a shared pointer to a
global pointer to a local integer, and the DW_AT_address_class attribute can
convey that.

Some of those CUDA segments are for radically different sorts of memory
(e.g. very low latency Shared memory vs. high latency Global memory).  But other
distinctions seem more gratuitous (e.g. Param vs. Global memory).  I assume that
there's a CUDA under-the-hood mapping of many of the segments to regions of a
flat Global address space in there, but the CUDA architectures & drivers
deliberately hide that mapping.  So effectively you end up with all the segments
being distinct, as far as a debugger can tell.


CUDA address spaces or a DSP with multiple distinct address spaces are 
what would conventionally be described as segmented memory.  I think 
that using the DW_AT_address_space would be reasonable.




On Thu, Jul 16, 2020 at 09:23:51AM +, Dwarf Discussion wrote:

Hello,



What would be the recommended way to model variables that are allocated to
different address spaces?



I found DW_OPT_xderef for dereferencing address-space qualified pointers
but the resulting memory location description wouldn't have an
address-space qualifier.



I found DW_AT_address_class, which allows attaching an integer, which
could represent the address-space.  This sounds pretty close.  I'm a bit
thrown off by the example, though.



Thanks,

Markus.





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

Re: [Dwarf-Discuss] modeling different address spaces

[John DelSignore via Dwarf-Discuss]

FYI, Tony Tye and his team at AMD created a DWARF Proposal for heterogeneous 
debugging, which is generally useful but required to debug optimized code for 
GPUs. It directly addresses the issue of how to model different address spaces 
and makes location descriptions first-class objects that can be push onto the 
evaluation stack.

https://llvm.org/docs/AMDGPUDwarfProposalForHeterogeneousDebugging.html

AFAIK, these changes will be made to LLVM and there is interest in adding to 
the DWARF standard eventually.

Cheers, John D.

On 2020-07-16 13:06, Todd Allen via Dwarf-Discuss wrote:
> Markus, Michael, David, Xing,
>
> I always assumed that the segment support in DWARF was meant to be more 
> general,
> and support architectures where there was no single flat memory, and so the
> segments were necessary for memory accesses.  I personally have not dealt with
> any architectures where DW_AT_segment came into play, though.
>
> Certainly x86 does not fall into that "truly distinct segments" category, at
> least not in modern times.  The segment registers there (fs & gs, for example)
> are an indirect way of specifying a base address within the flat address 
> space.
> They usually end up being used for thread-specific data structures where each
> thread has a different segment selector which implies a different base 
> address.
> And it requires a syscall to interact with the base addresses, at least on
> Linux.  The other segment registers (cs, ds, ss) are set-and-forget by the OS
> typically.
>
> The CUDA architecture is an interesting case.  It doesn't use DW_AT_segment at
> all.  But it does use the DW_AT_address_class attribute to specify CUDA 
> segments
> (e.g. Global, Local, Shared, among many others) for variables and/or types.  
> So
> it's fairly fine-grained.  You can, for example, have a shared pointer to a
> global pointer to a local integer, and the DW_AT_address_class attribute can
> convey that.
>
> Some of those CUDA segments are for radically different sorts of memory
> (e.g. very low latency Shared memory vs. high latency Global memory).  But 
> other
> distinctions seem more gratuitous (e.g. Param vs. Global memory).  I assume 
> that
> there's a CUDA under-the-hood mapping of many of the segments to regions of a
> flat Global address space in there, but the CUDA architectures & drivers
> deliberately hide that mapping.  So effectively you end up with all the 
> segments
> being distinct, as far as a debugger can tell.
>
> On Thu, Jul 16, 2020 at 09:23:51AM +, Dwarf Discussion wrote:
>>Hello,
>>
>>
>>
>>What would be the recommended way to model variables that are allocated to
>>different address spaces?
>>
>>
>>
>>I found DW_OPT_xderef for dereferencing address-space qualified pointers
>>but the resulting memory location description wouldn't have an
>>address-space qualifier.
>>
>>
>>
>>I found DW_AT_address_class, which allows attaching an integer, which
>>could represent the address-space.  This sounds pretty close.  I'm a bit
>>thrown off by the example, though.
>>
>>
>>
>>Thanks,
>>
>>Markus.
>>
> --
> Todd Allen
> Concurrent Real-Time
> ___
> Dwarf-Discuss mailing list
> Dwarf-Discuss@lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>
>
> CAUTION: This email originated from outside of the organization. Do not click 
> on links or open attachments unless you recognize the sender and know the 
> content is safe.

This e-mail may contain information that is privileged or confidential. If you 
are not the intended recipient, please delete the e-mail and any attachments 
and notify us immediately.

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

Re: [Dwarf-Discuss] modeling different address spaces

[Todd Allen via Dwarf-Discuss]

Markus, Michael, David, Xing,

I always assumed that the segment support in DWARF was meant to be more general,
and support architectures where there was no single flat memory, and so the
segments were necessary for memory accesses.  I personally have not dealt with
any architectures where DW_AT_segment came into play, though.

Certainly x86 does not fall into that "truly distinct segments" category, at
least not in modern times.  The segment registers there (fs & gs, for example)
are an indirect way of specifying a base address within the flat address space.
They usually end up being used for thread-specific data structures where each
thread has a different segment selector which implies a different base address.
And it requires a syscall to interact with the base addresses, at least on
Linux.  The other segment registers (cs, ds, ss) are set-and-forget by the OS
typically.

The CUDA architecture is an interesting case.  It doesn't use DW_AT_segment at
all.  But it does use the DW_AT_address_class attribute to specify CUDA segments
(e.g. Global, Local, Shared, among many others) for variables and/or types.  So
it's fairly fine-grained.  You can, for example, have a shared pointer to a
global pointer to a local integer, and the DW_AT_address_class attribute can
convey that.

Some of those CUDA segments are for radically different sorts of memory
(e.g. very low latency Shared memory vs. high latency Global memory).  But other
distinctions seem more gratuitous (e.g. Param vs. Global memory).  I assume that
there's a CUDA under-the-hood mapping of many of the segments to regions of a
flat Global address space in there, but the CUDA architectures & drivers
deliberately hide that mapping.  So effectively you end up with all the segments
being distinct, as far as a debugger can tell.

On Thu, Jul 16, 2020 at 09:23:51AM +, Dwarf Discussion wrote:
>Hello,
> 
> 
> 
>What would be the recommended way to model variables that are allocated to
>different address spaces?
> 
> 
> 
>I found DW_OPT_xderef for dereferencing address-space qualified pointers
>but the resulting memory location description wouldn't have an
>address-space qualifier.
> 
> 
> 
>I found DW_AT_address_class, which allows attaching an integer, which
>could represent the address-space.  This sounds pretty close.  I'm a bit
>thrown off by the example, though.
> 
> 
> 
>Thanks,
> 
>Markus.
> 

-- 
Todd Allen
Concurrent Real-Time
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] modeling different address spaces

[Michael Eager via Dwarf-Discuss]

On 7/16/20 2:23 AM, Metzger, Markus T via Dwarf-Discuss wrote:

Hello,

What would be the recommended way to model variables that are allocated 
to different address spaces?


Can you describe the architecture a bit?

I found DW_OPT_xderef for dereferencing address-space qualified pointers 
but the resulting memory location description wouldn’t have an 
address-space qualifier.


DW_OPT_xderef translates from an architecturally defined memory 
reference including an address space into a linear address space 
(generic type).  DWARF doesn't support computations on address-space 
qualified addresses, although using a typed stack, this could be an 
extension.


I found DW_AT_address_class, which allows attaching an integer, which 
could represent the address-space.  This sounds pretty close.  I’m a bit 
thrown off by the example, though.


Which example?

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

On 7/15/20 9:49 PM, David Blaikie wrote:



On Wed, Jul 15, 2020 at 7:07 PM Michael Eager via Dwarf-Discuss 
> wrote:


Segmented addresses have been in the DWARF specification since
Version 2
   and AFAIK have not been changed since that time.  DWARF V5 did
not add
any functionality to segmented addresses that was not present in DWARF
V2/3.  At least, there was no intention to do so.  Segmented addresses
are described in Section 2.12.

A segmented address maps into a linear address in a processor-specific
fashion. 



That seems at odds with the non-normative text of 2.12 "In some systems, 
addresses are specified as offsets within a given segment rather than as 
locations within a single flat address space."


That means that an x86 address could be represented as offset 0x1234 in 
segment 0x, which would translate to 0x0+0x1234=0x45674.  Note 
that x86 permits aliases, so that offset 0x0124 in segment 0x4555 is the 
same address.


DWARF sometimes uses wording which is intended to generalize a concept. 
Conceivably, another architecture could use the same DWARF attribute in 
a similar way.  That's why the non-normative text says "some systems" 
rather than specifically referencing x86.  But we do have that as the 
only example listed in the table.


And also would be confusing to me - if there is a contiguous linear 
address space, why would DWARF need to specify the use of a segment 
selector, and why do some references to addresses allow the inclusion of 
a segment selector and some don't? Why not just always use the 
non-segmented address description for DWARF?


So that a compiler can generate segment address values and offsets 
independently.  An x86 code generator may not know what segment it is 
generating code in.


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.


& I don't find any mention of this idea that some addresses are absolute 
and some are segment-relative in 2.12 - it does say that "If none of the 
entries in the chain of parents for this entry back to its containing 
compilation unit entry have DW_AT_segment attributes, then the entry is 
assumed to exist within a flat address space." - as though a flat (I 
assume this is synonymous with "linear"?) address space is distinct from 
the segmented address space being discussed otherwise?


Flat address space == linear address space.

From a certain perspective, x86 memory space is broken up into 65K 
16-byte segments mapped onto a 256K linear address range.




AFAIK, only the Intel 8086 and descendants have this
functionality.  (It's a many to one mapping in the 8086 implementation,
but that's a problem for a bygone era.)  There's a reference to i386
memory models in Table 2.7.

DWARF assumes a linear address space.  A segmented address maps to a
specific address in this linear address space.  The entries in
DW_AT_ranges for subprograms with different segment addresses would
usually be referenced by their address in the linear address space.  If
DW_AT_ranges has a DW_AT_segment, this is an indication that the
debugger is to perform the processor-specific computation to translate
the segment-address pair to the linear address.

There is no need to do anything with segments in the line table, since
the line table contains addresses in the linear address space.

There is some (perhaps considerable) confusion in terminology in the
x86
world, because the x86 has multiple segment registers which on other
processors would be called base registers.  The values in these
registers reference memory segments and are added to whatever offset is
contained in the program to generate an address.  These segment
registers, and the memory segments which they point to, are NOT the
segments represented by DW_AT_segment.

Re "reading the segment selector" and "addrx encoding":  The addresses
in DWARF DIEs are static, not dynamic.  There is no register+offset
encoding, and processor registers are not read to determine where a
subprogram is in memory.


Sorry, I don't quite follow the connections between all those statements.


Perhaps I didn't understand your comments about "reading the segment 
selector" and "addrx encoding".


TL;DR:
DW_AT_segment was designed to describe x86 memory model addresses: 
https://en.wikipedia.org/wiki/Intel_Memory_Model.


Possibly other architectures can use it, but I'm not familiar with any 
that do.



2.17 says that if a DIE has a DW_AT_high_pc and DW_AT_segment, then the 
high_pc is relative to the specified segment. That's a bit redundant if 
high_pc uses FORM_addrx, because the address in the address pool can 
specify its own segment, but a producer could choose which way to go 

[Dwarf-Discuss] modeling different address spaces

[Metzger, Markus T via Dwarf-Discuss]

Hello,

What would be the recommended way to model variables that are allocated to 
different address spaces?

I found DW_OPT_xderef for dereferencing address-space qualified pointers but 
the resulting memory location description wouldn’t have an address-space 
qualifier.

I found DW_AT_address_class, which allows attaching an integer, which could 
represent the address-space.  This sounds pretty close.  I’m a bit thrown off 
by the example, though.

Thanks,
Markus.

Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Gary Kershaw
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org