On Wed, Jul 15, 2020 at 7:07 PM Michael Eager via Dwarf-Discuss <
dwarf-discuss@lists.dwarfstd.org> 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."
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?
& 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?
> 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.
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 there.
(presumably if the AT_segment is there, you should interpret the addrx
high_pc relative to that segment - assuming debug_addr has no segment
selector in it - or perhaps it should go the other way and ignore the local
AT_segment and only rely on whatever segment is in debug_addr)
>
> On 7/15/20 4:31 PM, David Blaikie via Dwarf-Discuss wrote:
> > Looking at how segment selectors work:
> >
> > DW_AT_segment: Applies to a DIE subtree, including any ranges, high/low
> > pc, locations, labels, etc
> > debug_range/loc (v4 and below): Doesn't seem to allow specifying segment
> > variation - inherits from the segment given on the nearest parent DIE
> > that refers to the entry
> > debug_rnglist/loclist (v5): includes segment selector size in the
> > header, but doesn't seem to use it - segment selection via addresses in
> > the address pool (RLE/LLE_*x encodings) would allow fine-grained segment
> > selection, but direct address forms don't seem to allow segment
> > selection ("This operand is the
> > 19 same size as used in DW_FORM_addr.")
> > debug_addr: segment_size in header, then list of {segment selector,
> address}
> > debug_aranges: segment_size in header says, then the list contains
> > triples of {segment selector, start address, length}
> > debug_line: v5 encodes the address and segment selector size in the
> > header, but I'm not sure if/how it's used. The DW_LNE_set_address
> > operation says:
> > "The DW_LNE_set_address opcode takes a single relocatable address as an
> > operand. The size of the operand is the size of an address on the target
> > machine. It sets the address register to the value given by the
> > relocatable address and sets the op_index register to 0." - doesn't
> > sound like it's reading the segment selector there.
> >
> > So... I don't think DWARFv5 made anything worse - if anything it did
> > enable /a/ way to use fine grained segment selectors in range lists and
> > location lists that doesn't appear, to me, to have been provided before.
> > (it could be needed if you had some functions in some segment and some
> > functions in another segment (which could be represented at the
> > subprogram DIE level - DW_AT_segment 1 on one DW_TAG_subprogram,
> > DW_AT_segment 2 on another DW_TAG_subprogram - but how would you
> > represent the DW_AT_ranges for this CU (in DWARFv4, or in DWARFv5
> > without using addrx encodings)? I don't know how, because I think
> > debug_ranges could describe one range list entry as being from one
> > segment, and another range list entry as being in another segment - they
> > would all be in whatever segment was in DW_AT_segment on the CU)
> >
> > does that make sense? Have I missed something about how you could use
> > segment selectors in a debug_loc, debug_ranges, or loclist/rnglist that
> > isn't using an addrx encoding?
> >
> > On Wed, Jul 15, 2020 at 6:37 AM Robinson, Paul via Dwarf-Discuss
> > <dwarf-discuss@lists.dwarfstd.org
> > <mailto:dwarf-discuss@lists.dwarfstd.org>> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Dwarf-Discuss <dwarf-discuss-boun...@lists.dwarfstd.org
> > <mailto:dwarf-discuss-boun...@lists.dwarfstd.org>> On Behalf
> > > Of Xing GUO via Dwarf-Discuss
> > > Sent: Tuesday, July 14, 2020 10:39 PM
> > > To: dwarf-discuss@lists.dwarfstd.org
> > <mailto:dwarf-discuss@lists.dwarfstd.org>
> > > Subject: [Dwarf-Discuss] Segment selectors for the range list
> table.
> > >
> > > Hi there,
> > >
> > > The DWARFv5 spec mentioned that there might be segment selectors
> in
> > > the range list entries and when the segment_selector_size is 0,
> the
> > > segment selectors are omitted from the range list entries.
> > However, it
> > > didn't mention how the segment selector should be encoded when the
> > > segment_selector_size isn't 0. Can anyone help me figure it out?
> > > Thanks a lot!
> >
> > Hi Xing,
> >
> > The segment selectors in the range list would be encoded the same way
> > as they would be in the main .debug_info section. Range lists and
> > location lists are essentially extensions to .debug_info, for cases
> > where the range or location cannot be represented by simple DW_AT_*
> > attribute values.
> >
> > The specifics of encoding the segment selector would be whatever is
> > appropriate to the target. DWARF does not specify these details.
> >
> > Best Regards,
> > --paulr
> >
> >
> > >
> > > 7.28 (page 243)
> > > The segment size is given by the segment_selector_size field of
> the
> > > header, and the address size is given by the address_size field
> > of the
> > > header. If the segment_selector_size field in the header is zero,
> the
> > > segment selector is omitted from the range list entries.
> > >
> > > --
> > > Cheers,
> > > Xing
>
>
>
> --
> Michael Eager
> _______________________________________________
> 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
