This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]