This is the mail archive of the
dwarf2@corp.sgi.com
mailing list for the dwarf2 project.
IA-64 issue H-1: Return address register number
- To: dwarf2 at baalbek dot engr dot sgi dot com
- Subject: IA-64 issue H-1: Return address register number
- From: dehnert at baalbek dot engr dot sgi dot com (Jim Dehnert)
- Date: Tue, 4 Apr 2000 15:11:32 -0700 (PDT)
- Reply-To: dehnert at baalbek dot engr dot sgi dot com (Jim Dehnert)
> From davea@quasar Mon Apr 3 16:50:57 2000
>
> Jim, note that there is a restriction in dwarf
> in .debug_frame that means the
>
> dwarf number
>
> for the return address register should be <= 255 (fit in
> an unsigned byte).
>
> This is of little practical importance since .debug_frame is
> not being used, but for a *dwarf* numbering it seems
> silly to make it impossible to create .debug_frame at all.
We have an issue here with our register numbering, which assigns 1-127
to the GRs and 128-255 to the FRs, leaving nothing in the one-byte
range for the return address "register" (which is not an actual
register but an abstract register). We have three choices that I
see:
1) Ignore it. Noone currently intends to use debug_frame for
IA-64, as we are using the ABI unwind info instead. See (3).
2) Shift our numbering of the registers to leave a hole for the
return address register, e.g. move the FRs to 129+ (or higher).
3) The problem occurs in the CIE header for debug_frame, where the
return address is currently specified as a ubyte. The CIE also has
a version number, so we could bump the version number and use a
ULEB for the return address field. That change has been suggested
as a generic DWARF change, but I imagine IA-64 implementations
could choose to do it in any case.
(1) is easiest today, but has a minor chance of causing confusion in
the future if debug_frame implementations arise. (2) is cleanest,
but might be a minor compatibility problem with already-existing IA-64
implementations. (3) is OK if the base DWARF group adopts it anyway,
but might be problematic if they don't.
What are your thoughts, especially the current IA-64 implementors?
Jim
- Jim Dehnert x3-4272