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

[Andrew Cagney <cagney@gnu.org>]

>    From: Ulrich Weigand <weigand@i1.informatik.uni-erlangen.de>
>    Date: Sat, 13 Dec 2003 16:32:12 +0100 (CET)
>    Cc: cagney@gnu.org, weigand@i1.informatik.uni-erlangen.de,
>       gdb-patches@sources.redhat.com, uweigand@de.ibm.com
>    Content-Type: text/plain; charset=us-ascii
>    X-Spam-Level: 
>    X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
> 	   elgar.kettenis.dyndns.org
>    X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
> 	   version=2.60
> 
>    Mark Kettenis wrote:
> 
>    > I've considered per-architecture initialization of the unwind table
>    > before.  However, the things Richard Henderson says about treating
>    > uninitialized columns as "same value" make sense.
> 
>    However, I rather like to see 'value not available' instead of
>    an incorrect value in an 'info reg' display.  So if we do have
>    an arch-dependent callback, we might as well use ABI knowledge
>    to get this right.
> 
> It probably depends a bit on the context.  IMHO it is perfectly
> all-right for a compiler to generate code that doesn't conform to the
> ABI if it knows what it's doing.  Or for to user to ask the compiler
> to generate code that doesn't conform to the ABI.  IIRC this happens
> at various places in glibc.  It would be a bit unfortunately if we
> made it hard or impossible for the user to view (valid) variables in
> registers, just because we're strictly enforcing the ABI.  Of course
> the real solution here would be to get GCC to emit CFI for all
> registers, at least for .dwarf_frame (as opposed to .eh_frame)
> sections.

Let me scare you a little ....

GCC is working towards to being able to do non-ABI local function calls 
(and knowing them a few global ones as well :-)

With that said, I think for values, GDB should print value-unknown, but 
for registers, print the likely wrong value (we could always add "info 
known-registers" :-).  But its a judgment call, anyone want to toss the 
coin?

>    > In the meantime, I'm going to try to remove some of the PC and
>    > SP-related hacks in dwarf2-frame.c and see what happens.
> 
>    The only hack that cannot be replaced using the rules described
>    above (as far as I can see) is the 
>      if (column == fs->retaddr_column)
>        continue;
>    in dwarf2_frame_cache.  Does any platform rely on this behaviour?
> 
> The reason why I added that hack in the first place is the case where
> the return address column does not correspond to an actual register.
> In that case we must make sure that we don't map it onto one of GDB's
> (pseudo-)registers.  Assuming that the compiler has some freedom in
> choosing the return address column number, and considering that the
> DWARF-2 register numbers are largely undocumented for most targets, I
> was worried that I couldn't guarantee this.
> 
> AFAICT there is no platform yet where GCC uses a return address column
> number that would be mapped on the wrong GDB register, so I think we
> can safely remove the code.  New targets that start using the DWARF-2
> CFI stuff should make sure theur DWARF-2 register number mapping is
> right.

Well, ... the PPC64 return-column, when I last looked, specified the 
dwarf2' floating-point status and control register number!  But let the 
person framifying the PPC64 sort that one out :-)

Anyway, with respect to your proposal, yes like it.

Andrew