On Thu, Jul 16, 2020 at 4:25 PM Michael Eager <ea...@eagercon.com> wrote:
> On 7/16/20 2:57 PM, David Blaikie wrote: > > > > > > On Thu, Jul 16, 2020 at 2:05 PM Michael Eager <ea...@eagercon.com > > > > You appear to be starting with a counterfactual premise and using > that > > to postulate a problem where none exists. > > > > > > Sorry - I seem to be misunderstanding what you mean by "there are no > > restrictions on where code or data are located" - I understood that to > > mean different bits of code could be in different segments. > > It does no one good when you take a comment about one point > (.debug_aranges) and contort it to apply to an unrelated point > (DW_AT_segment). > The language used to describe segmented addressing in DW_AT_segment reads to me like the same language used to describe segmented addresses in debug_aranges - it reads to me like they refer to the same concept. What aspect of the wording do you find distinguishes between these two discussions on segmented addresses? > Reread my previous comment about the meaning of segment as used in > DW_AT_segment. You apparently want it to mean something different. > There seems to be some significant disconnect between how we're each understanding these concepts - could you help me understand/perhaps use different language that might help me understand/connect with your reading/understanding here? I'm trying my best to understand what the spec is saying/how to interpret it. > As previously stated, DW_AT_segment provides a way to represent x86 > > segmented addressing. Each segmented address is mapped to an > > address in > > a linear address space. The mapped address can be used in the > ranges. > > > > > > Where does the spec say that? How do we construct an answer to the > > original question from this thread from the words in the spec? > > There are many things that the spec does not say about implementation. > We sometimes suggest best practices, but we don't require implementors > to follow them. The DWARF spec is also not written to prevent > implementors from doing things badly. > > Providing an example of the use of DW_AT_segment provides a strong hint > of how it may be used, without constraining it to one specific > architecture, or preventing it from being used in other ways. When we > have had discussions about whether to give more specific implementation > details, we have frequently decided to let matters go with a hint, > rather than a prescription. > > While we cannot prevent people from misreading or misinterpreting the > DWARF spec, we try to answer questions as they arise. > > Having been told how address ranges might be implemented for x86 > segmented addresses, is there more to add? > You've mentioned they can be used - but I'm still pretty confused by how they would be used to achieve that result. Do you happen to know of an implementation that uses them in this way/any examples of DWARF using the feature? I think that'd be realyl helpful to ground the discussion with concrete examples. My reading still seems to indicate that all the dwarf sections are meant to use segment-relative addresses (all the wording for address size says it should be the segment-relative address size, not an address in an alternative linear address space) It sounds like you're suggesting that an implementation may choose on a per-section basis whether to use segmented addressing (because this assumes an existing alternative linear addressing per x86) - and that some sections /require/ the use of that linear addressing mode. Is that the idea? But the segmented addressing section seems to say "addresses are specified as offsets within a given segment rather than as locations within a single flat address space" - sounds like it's talking about systems where there is no flat address space, in which case the sections requiring a linear addressing would present a problem when it comes to rendering them in DWARF. > > > I don't especially have a need for segmented addresses myself - so I may > > not be the best person to push for changes/clarifications here - I was > > trying to answer the original poster's question using what I can see > > from the spec. > > It's rarely beneficial to get into a hypothetical debate. If you have > no use case and are just postulating problems for which there is no > evidence, there isn't much to be gained pursuing this. > The use case seems to be the original poster's question - and some questions/uncertanties I had when reading the spec to try to understand it to answer the question. > You appear to be reading the standard to mean something other than > what > > it says. FORM_addrx is a method to compress FORM_addr, nothing more. > > > > > > But it describes segmented addresses - it says so specifically, doesn't > > it? Using the same wording that is used to describe segmented addresses > > elsewhere in the spec. > > DWARF uses the same description for segmented addresses almost > everywhere that an address is used. This is for consistency. The > meaning is the same everywhere. > If the meaning is the same everywhere, then it seems strange that it's not supported everywhere (such as debug_rnglist/ranges) - the meaning used in 2.12 seems to talk about a possible architecture that can only be addressed via segmented addressing, without an alternative linear address space - yet there are bits of DWARF where support for such an architecture seems to be missing/incomplete. I'd love to see some concrete examples of this sort of DWARF if you know of any producer that uses this feature. - Dave
_______________________________________________ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
