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

[Michael Eager]

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