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

[Mark Kettenis <kettenis at chello dot nl>]

   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.

   > 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.

Mark