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