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

Andrew Cagney
2003-12-14T16:40:59Z

> 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