[parisc-linux] Re: pa __builtin_return_addr

[law@redhat.com]

  In message <Pine.LNX.4.30.0105052051010.7143-100000@mullet.itr.unisa.edu.au>y
ou write:
  > Hi Jeff,
  >   I stumbled on this one a couple of hours ago, and haven't figured out
  > a good fix yet.
  > 
  > cat >builtin_ret.c <<EOF
  > void *foo (void) { return __builtin_return_address (0); }
  > EOF
  > gcc -O -S -mno-space-regs builtin_ret.c
  > 
  > gives (trimming somewhat)
  > foo:
  >         bv %r0(%r2)
  >         ldw -20(%r30),%r28	# Oops, we never stored r2 at -20(%r30)
  > 
  > The fix I have in mind is to add some communication between
  > builtins.c:expand_builtin_return_addr and pa.c:hppa_expand_prologue.
  > eg. add a field to struct machine_function, and set it in
  > pa.c:return_addr_rtx to indicate that r2 must be saved.
The "right" way to handle this would be to have return_addr_rtx return
%r2 in the case where %r2 isn't ever saved into the stack.  However, I
don't know if we can reliably determine if %r2 is saved into the stack
at the point where we call return_addr_rtx.

If we can't reliably make that determination, then we can just force
%r2 to be saved into the stack if we ever call __builtin_return_address.

  > A similar problem occurs with
  > cat >builtin_frame.c <<EOF
  > void *foo (void) { return __builtin_frame_address (1); }
  > EOF
  > gcc -O -S builtin_frame.c
  > 
  > foo:
  >         bv %r0(%r2)
  >         ldw 0(%r30),%r28	# Oops, we haven't saved a frame pointer.
  > 
  > We ought to be able to make __builtin_frame_address (n) work reliably for
  > n = 0 and n = 1 by something similar to the fix I'm proposing for the
  > return address problem.  ie. set a "frame_pointer_needed" flag in
  > struct machine_function.
I disagree about the solutoin for this one.  I believe it should be 
possible to derive the frame address from the stack pointer fairly
easily since the difference between the stack and frame pointer is
a constant.

jeff