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

Andrew Cagney
2003-12-10T17:14:56Z

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