[Dwarf-Discuss] DW_AT_segment and relocation
jayvee.neumann at gmail.com
Sun Sep 29 23:25:07 PDT 2019
Thank you Ron and thank you Michael,
this explanation helps me a lot.
I think I do not have to support 286 and 386 in 16bit mode. So, this
simplifies things a lot.
Am Sa., 28. Sept. 2019 um 00:04 Uhr schrieb Michael Eager <eager at eagerm.com
> On 9/27/19 1:29 AM, Jayvee Neumann wrote:
> > Thank you Michael and Ron,
> > what I am trying to do is write a consumer that is able to handle images
> > from several targets: i386, AMD64, and also ARM. The target images will
> > be loaded and running (and debugged during run-time).
> > I want to find a way to handle addresses in a simple way, abstracting
> > from the underlying architecture. So my first Idea was giving each
> > address a segment that can either be zero or an expression.
> > That lead to the problem I mentioned in the first email. I think this is
> > best explained with an example. If the image (e.g. a DLL or a shared
> > library) has a preferred loading address of 0x1000, this address is used
> > in DWARF. But the image could be loaded at e.g. 0x2000 (or any other
> > address). The consumer has to adjust all the pc values in DWARF in that
> > case. A function whose DWARF information say is loaded from e.g. 0x10E8
> > to 0x1120 is actually loaded from 0x20E8 to 0x2120. An attribute
> > DW_AT_low_pc with the value 0x1500 would represent the address 0x2500
> > when the image is actually loaded. But an address like Segment:Offset
> > (e.g. CS:0x0123) would be valid during run-time without any adjustment,
> > since the segment is computed from registers during run-time and thus
> > necessarily adjusted to the load-time addresses and not build-time
> > addresses. So the rule of thumb would be: Do not adjust segmented
> > addresses in the consumer. Or have I misunderstood something about this
> > matter?
> When it reads the debug info, a debugger has to go through the same
> relocation process as happens when the executable or library is loaded.
> Every relocatable reference needs to be adjusted to account for the
> situation you describe, where the code is loaded at a different offset.
> DW_AT_segment really cannot be used to do this. There is (in general)
> no register or other expression which will perform this relocation for
> you, since the computation depends on information (e. g., the load
> addresses for each piece of the executable) which may not be accessible
> to the program.
> Unless you are planning to support 286 or 386 in 16-bit mode in one of
> the segmented memory schemes used on these processors, you do not need
> support for DW_AT_segment.
> > What is kind of counter intuitive is the fact that the DWARF5 standard
> > says: if DW_AT_segment is specified at any parent DIE it is valid at its
> > subsequent child DIEs. Consumer libraries like libdwarf have no function
> > that allows for determining the parent DIE if only the child DIE is
> > known. It would be necessary to go through all DIEs and check which one
> > is an ancestor of the DIE in question. So this little sentence implies a
> > lot of difficulties for a consumer.
> I haven't looked at how debuggers like GDB handle segments in a very
> long time. I believe that when the DWARF info is read and used to
> create an internal representation, a current segment value is maintained
> as the debug info is parsed recursively. This is set as you descend the
> parse tree, pushing previous values, and popped when ascend the tree.
> Almost all architectures, and specifically the ARM and AMD64
> architectures you mention, use linear, not segmented, address spaces.
> > Kind regards,
> > Jayvee
> > Am Do., 26. Sept. 2019 um 23:12 Uhr schrieb Michael Eager
> > <eager at eagerm.com <mailto:eager at eagerm.com>>:
> > On 9/26/19 3:33 AM, Jayvee Neumann via Dwarf-Discuss wrote:
> > > Dear DWARF experts,
> > >
> > > I have a question regarding the attribute DW_AT_segment. I do not
> > quite
> > > understand how to handle it, yet.
> > > It can appear in a DIE (or its parent) whenever DW_AT_low_pc,
> > > DW_AT_high_pc, DW_AT_ranges, DW_AT_entry_pc, or a location
> > description
> > > that evaluates to an Address are used.
> > > It can contain a location expression itself. So it can depend not
> > only
> > > on compile-time information but also on run-time information.
> > >
> > > Assume, I have an attribute DW_AT_low_pc. If there is no
> > DW_AT_segment,
> > > this attribute is simply the low_pc as it was determined during
> > > compile-time. While debugging, this value has to be relocated if
> > > image had been relocated. If there is a DW_AT_segment expression
> > > relocation still necessary? Evaluating the expression could also
> > > incorporate the usage of run-time information and relocated
> > addresses
> > > (i.e. the DS/CS/SS registers).
> > >
> > > I hope I was able to articulate my question well, English is not
> > > native language.
> > >
> > > Kind Regards
> > > Jayvee
> > Your question is quite clear, but we don't know the context. What
> > architecture are you working with and what ar you trying to do?
> > As Ron mentioned, AT_segment is intended to support architectures
> > the X86 where an address is composed of a [segment,offset] pair.
> > architectures do not use segments.
> > --
> > Michael Eager eager at eagerm.com <mailto:eager at eagerm.com>
> > 1960 Park Blvd., Palo Alto, CA 94306
> Michael Eager eager at eagerm.com
> 1960 Park Blvd., Palo Alto, CA 94306
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Dwarf-Discuss