Re: dwarf2 and frame bases

[Mark Kettenis <kettenis at gnu dot org>]

   Date: Thu, 11 Nov 2004 08:48:52 -0800
   From: Randolph Chung <randolph@tausq.org>

   sounds like it should still work (i.e it should still be a valid
   address), except the hppa targer has an explicit check for when we
   expect r3 to be modified but we may be in the process of changing it
   (since it's a 3 insn sequence). In that case, we zero the register to
   tell the unwinder not to use the value in the r3 to calculate the frame
   base (it uses the stack pointer and other unwind information in that
   case)

   See http://sources.redhat.com/ml/gdb-patches/2004-06/msg00108.html for
   more details.

   i know it is kind of hacky, but the frame unwinding code is explicitly
   asking "what is the frame base of this frame", and the target code is
   especially tuned for that..... 

It is certainly hacky, and defenitely wrong.  "Thou shallt not lie
about your register contents".  

   i see two possible solutions:
   1) perhaps the hppa target should use some other mechanism (instead of 
      mucking with r3) to tell the next frame that the frame pointer is 
      not available.....

Why does the next frame need that frame pointer?

   2) in the dwarf code, when trying to get the frame base, should we
      explicitly ask for the frame base instead of using the dwarf 
      expression? perhaps this could be something that can be overridden
      by the target, so that the default still uses the dwarf information.

The problem here is that the debug information provided my the
compiler is wrong, or at least incomplete.  This should be fixed in
the compiler, not in GDB.  Unfortunately this probably means we need
to have proper support for location expressions in GDB.

Mark