On Thu, Jul 16, 2020 at 2:05 PM Michael Eager <ea...@eagercon.com> wrote:
> On 7/16/20 1:36 PM, David Blaikie wrote: > > > > > > On Thu, Jul 16, 2020 at 1:07 PM Michael Eager <ea...@eagercon.com > > <mailto:ea...@eagercon.com>> wrote: > > > > > Perhaps it's more like Paul was postulating - that the spec > > assumes code > > > is in a code segment/doesn't need to be clarified. (but that gets > > a bit > > > confused in debug_aranges - if it only is meant to contain code > (not > > > data), why does it need a segment selector - and also in the DIEs > > - if > > > code is always in a known/assumable segment then why can you vary > > > segment for low_pc/high_pc/ranges?) > > > > No, the spec says what it says. There are no restriction on where > > code > > or data are located. > > > > > > OK - then if subprograms can be in different segments, how would the > > ranges on the CU be used to describe that? It seems to me that a range > > list can't contain regions in more than one segment, which presents a > > problem for describing such a situation, no? > > 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 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. > 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. > Done.
_______________________________________________ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
