On Wed, Jul 15, 2020 at 8:00 PM Xing GUO <higuox...@gmail.com> wrote:
> Hi David,
>
> On 7/16/20, David Blaikie <dblai...@gmail.com> 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.")
>
> Thanks for your explanation.
>
Note: there seems to be some disagreement with my understanding - and I
haven't been around these parts nearly as long as some other folk - so
there's a fair chance I'm wrong/misunderstanding/misreading things.
> So, If we want to use segmented addresses in the debug_rnglist or
> debug_loclist table, we should use encodings like: startx_endx,
> startx_length, etc., to index the {segment/address} pairs in the
> address table of the .debug_addr section rather than the direct
> address forms like: start_end, start_length, etc., right?
>
That's /my/ understanding. (side note: imho: it's good to use the addrx
forms anyway - since you can reduce relocations (& thus object size) that
way - try some experiments with Clang's DWARFv5 support to see how I
implemented it there/how I think it should be done (admittedly I have a
bias towards reducing object size especially, since that's a particular
issue for my customers))
> Besides, the segment_selector_size is just an indicator that tells us
> if the current debug_rnglist/debug_loclist table is using segmented
> address and it should have no effects on parsing the encoding and
> operands (e.g., {DW_RLE_startx_endx, operands0, operands1},
> {DW_RLE_start_end, operands0, operands1}) in the entries.
>
None that I can see - which seems suspicious to me. (similarly in
debug_line - there's a segment_selector_size in the header, but no use that
I know of in the actual parsing of the implementation... )
>
> > 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> wrote:
> >
> >>
> >>
> >> > -----Original Message-----
> >> > From: Dwarf-Discuss <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
> >> > 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
> >> > _______________________________________________
> >> > Dwarf-Discuss mailing list
> >> > Dwarf-Discuss@lists.dwarfstd.org
> >> >
> >>
> https://urldefense.com/v3/__http://lists.dwarfstd.org/listinfo.cgi/dwarf-
> >> > discuss-dwarfstd.org__;!!JmoZiZGBv3RvKRSx!v6qFHG-
> >> > c16QgrlK07KDC5v6Q8edq8S8mb3_4iif7SZxPna-t0k5tZRaMoXPgqvftiQ$
> >> _______________________________________________
> >> Dwarf-Discuss mailing list
> >> Dwarf-Discuss@lists.dwarfstd.org
> >> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
> >>
> >
>
>
> --
> Cheers,
> Xing
>
_______________________________________________
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
