[PATCH] S/390 DWARF-2 CFI frame support

Andrew Cagney cagney@gnu.org
Wed Dec 10 17:14:00 GMT 2003


Mark,

This is really a question for you.  If you want I can hack up the code 
(although I don't know exactly when that would happen).

Andrew

> Hello,
> 
> this patch adds support for DWARF-2 frame handling to the s390 backend.
> 
> However, the DWARF-2 frame common code makes a couple of assumptions
> that are not valid on s390:
> 
> - The return address column is not unwound into the specified register,
>   only into the PC.  On s390, it should be unwound into both.
> 
>   The patch below fixes this by unwinding into both register
>   and PC if the return column corresponds to a GDB register.
> 
> What does the CFI output look like here?  (I'm mainly curious but it always helps to have concrete examples).
> 
> For a variant of the PPC64 GCC I found:
> 
> - return column pointed at the FSCR
> (which is stupid)
> 
> - return column same-value as "LR" was implied
> (which is contrary to the DWARF2's example, and what you also encountered)
> 
> this means that we've now got the following initial states all mapping onto "unspecified":
> 
> - same value
> - unknown
> - (for SP_REGNUM) it's the CFA (but is it one frame out?)
> - (for return column) it's the LR
> 
> I'm wondering if it would be easier, here to "give up".  Throw the whole problem back at the architecture vis:
> 
> - initialize unwind table using per OSABI (?) method
> 
> - update the unwind table using the CFI initialize info
> 
> - update the unwind table using the PC's CFI unwind info
> 
> - if after all this a register is still unspecified, we complain
> (btw, the compaint is only ment to appear once but apparently appears repeatedly?).
> 
> Thoughts for the moment on the theory?  Mark?
> 
> It should also open the way for the elimination of SP_REGNUM and PC_REGNUM from this file (ya!).
> 
> As for an interface, the <ARCH>_gdbarch_init code could something like:
> 
>     dwarf2_frame_add_sniffer (gdbarch, (*<ARCH>_dwarf2_cfi_init) (struct cfi_table *table));
> 
> (but with better names :-).
> 
> Andrew




More information about the Gdb-patches mailing list