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.
Kind regards Jayvee Am Sa., 28. Sept. 2019 um 00:04 Uhr schrieb Michael Eager <ea...@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 > > <ea...@eagerm.com <mailto:ea...@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 > the > > > image had been relocated. If there is a DW_AT_segment expression > is > > > 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 > my > > > 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 > like > > the X86 where an address is composed of a [segment,offset] pair. > Most > > architectures do not use segments. > > > > -- > > Michael Eager ea...@eagerm.com <mailto:ea...@eagerm.com> > > 1960 Park Blvd., Palo Alto, CA 94306 > > > > -- > Michael Eager ea...@eagerm.com > 1960 Park Blvd., Palo Alto, CA 94306 >
_______________________________________________ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
