This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Register window support in DWARF-2
- From: Eric Botcazou <ebotcazou at libertysurf dot fr>
- To: gcc at gcc dot gnu dot org
- Cc: Jason Merrill <jason at redhat dot com>
- Date: Wed, 24 Nov 2004 00:26:11 +0100
- Subject: Register window support in DWARF-2
Hello Jason,
Up to 3.4.x, the SPARC port was using an asm prologue/epilogue and, therefore,
manually building its call frame debugging information with the help of
dwarf2out_window_save and dwarf2out_return_reg. We now have switched to an
RTL prologue/epilogue and the debug info emitted manually is not accurate
anymore.
So we would need to set RTX_FRAME_RELATED_P on the appropriate insns and let
the DWARF-2 backend do the bulk of the work. Of course there is a problem
since no rule is implemented in dwarf2out_frame_debug_expr to deal with
register windows.
Here's the typical SPARC 64-bit call frame debug info:
.LLframe1:
.uaword .LLECIE1-.LLSCIE1 ! Length of Common Information Entry
.LLSCIE1:
.uaword 0x0 ! CIE Identifier Tag
.byte 0x1 ! CIE Version
.ascii "\0" ! CIE Augmentation
.byte 0x1 ! uleb128 0x1; CIE Code Alignment Factor
.byte 0x78 ! sleb128 -8; CIE Data Alignment Factor
; Initial instructions
.byte 0xf ! CIE RA Column Return Address register %o7
.byte 0xc ! DW_CFA_def_cfa CFA at
.byte 0xe ! uleb128 0xe %sp
.byte 0xff,0xf ! uleb128 0x7ff + 2047
.align 8
.LLECIE1:
.LLSFDE5:
.uaword .LLEFDE5-.LLASFDE5 ! FDE Length
.LLASFDE5:
.uaword .LLASFDE5-.LLframe1 ! FDE CIE offset
.uaxword .LLFB4 ! FDE initial location
.uaxword .LLFE4-.LLFB4 ! FDE address range
; Call Frame instructions
.byte 0x4 ! DW_CFA_advance_loc4
.uaword .LLCFI2-.LLFB4
.byte 0xd ! DW_CFA_def_cfa_register
.byte 0x1e ! uleb128 0x1e CFA at %fp + 2047
.byte 0x2d ! DW_CFA_GNU_window_save
.byte 0x9 ! DW_CFA_register
.byte 0xf ! uleb128 0xf %o7 ->
.byte 0x1f ! uleb128 0x1f %i7
.align 8
.LLEFDE5:
I think it would not be very difficult to automatically generate
.byte 0xd ! DW_CFA_def_cfa_register
.byte 0x1e ! uleb128 0x1e CFA at %fp + 2047
using rule #1 and a well-chosen PARALLEL. The problem pertains to generating
.byte 0x2d ! DW_CFA_GNU_window_save
.byte 0x9 ! DW_CFA_register
.byte 0xf ! uleb128 0xf %o7 ->
.byte 0x1f ! uleb128 0x1f %i7
The "save register window" insn is modelled with an UNSPEC_VOLATILE in the RTL
stream. What about adding a new rule to handle UNSPEC_VOLATILEs with the
help of a new target hook? Something like:
Rule 15:
(set <reg> {unspec, unspec_volatile})
effects: target-dependent
Thanks in advance.
--
Eric Botcazou