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
