PING [RFC] Fix MIPS frame prologue scan problem

["Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>]

    Hi Marciej,

  I didn't get any answer on the question I raised 
on the bottom of my answer to your comments.

  I just summarize here:
1) It's true that my pot might not be ABI complaint, but I saw
several other assembly code that use the same approach (it might
be really old assembler)
2) The current code in mips-tdep.c should either 
handle the 
  add $s8, $sp, LOCALSIZE
in a way similar to what I propose or
otherwise at least complain about non-ABI code, no?

Pierre

> -----Message d'origine-----
> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Pierre Muller
> Envoyé : vendredi 22 juin 2012 08:53
> À : 'Maciej W. Rozycki'
> Cc : 'GDB Patches'
> Objet : RE: [RFC] Fix MIPS frame prologue scan problem
> 
> 
> 
> > -----Message d'origine-----
> > De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> > owner@sourceware.org] De la part de Maciej W. Rozycki
> > Envoyé : vendredi 22 juin 2012 01:12
> > À : Pierre Muller
> > Cc : 'GDB Patches'
> > Objet : Re: [RFC] Fix MIPS frame prologue scan problem
> >
> > Hi Pierre,
> >
> >  Sorry about the delay, I've been swamped with stuff recently.
>  Thanks for your reply.
> 
> > On Wed, 13 Jun 2012, Pierre Muller wrote:
> >
> > >   I am trying to extend the Free Pascal compiler to support
> > > MIPS architecture.
> > >
> > >   From what I read so far, register $s8 (register number 30) can be
used
> > as
> > > a frame register,
> > > but when I set $s8 to the value of the stack pointer ($sp, register
> number
> > > 29)
> > > I get all my locals and parameter of functions wrong.
> > >
> > >   I traced it down to the fact that GDB seems to use a
> > > 'virtual' frame pointer register called $fp,
> > > but which is miscalculated in my case.
> > >
> > >   In GCC generated code, $s8 register gets the same value as
> > > $sp register, so that this problem does not show up in that case,
> > > but for me, if I have a prologue that reserves 80 bytes,
> > > I will typically get
> > >
> > >   # Reserve 80 bytes for locals and area for called function
parameters
> > >   addi $sp,$sp,-80
> > >   # Save $ra and $s8 registers, there could be others...
> > >   sw    $ra,44($sp)
> > >   sw   $s8,40($sp)
> > >   # Set $s8 to function entry value of $sp
> > >   addi $s8,$sp,80
> > >
> > >   Analysis of first instruction leads to setting of
> > > frame_offset to 80.
> > >
> > >   The problem is that when the last instruction
> > > is analyzed by mips32_scan_prologue,
> > > it switches the frame_reg from $sp to $s8,
> > > but does not modify frame_offset value.
> > >   This leads to a frame pointer $fp
> > > being computed as $s8 + frame_offset
> > > which is equal to $sp + 2*frame_offset.
> > >   Thus all my locals are wrong :(
> > >
> > >   Substraction of the constant in the last addi instruction (low_word)
> > > to frame_offset seems to cure my problem.
> >
> >  Well, to put it short, you're not supposed to do that if you want to
> > follow the MIPS ABI.  The MIPS processor has no hardware stack and the
> > software implementation of the stack has been made such that there is
> > generally no need to arrange for a hard frame pointer (in a register
> > separate from the stack pointer), except where dynamic stack allocation
> > is used (alloca in C terms).
> 
>   I tried to read several MIPS documents,
> and the message was not that clear to me...
> 
> >  Therefore the right place to look for how the hard frame pointer has
been
> > specified is the "Dynamic Allocation of Stack Space" section in Chapter
3
> > "Machine Interface" of the MIPS psABI document:
> >
> > "When a function requires dynamically allocated stack space it manifests
a
> > frame pointer on entry to the function.  The frame pointer is kept in a
> > callee-saved register so that it is not changed across subsequent
function
> > calls.  Dynamic stack allocation requires the following steps.
> >
> >  1. On function entry, the function adjusts the stack pointer by the
size
> >     of the static stack frame.  The frame pointer is then set to this
> >     initial sp value and is used for referencing the static elements
> >     within the stack frame, performing the normal function of the stack
> >     pointer."
> >
> >  So in fact both GCC and GDB are correct, you're not supposed to add a
> > constant to the stack pointer when calculating the value of the frame
> > pointer -- it is supposed to hold the value of the stack pointer *after*
> > the frame has been allocated (in other words any frame offsets are
> > non-negative).
> 
>   Our current problem is that we don't yet knoow the
> stacksize that we need for the function while we generate
> its code, so that using a frame pointer at previous value of stack pointer
> makes this
> really easier for now.
> 
> >  You need to adjust your code generated (BTW, note that the
> > convention assumed by the ABI is to use non-trapping arithmetic; I'm
> Is this the difference between
>   ADDI and ADDIU?
> I thought it was only a signed/unsigned difference,
> Do that mean that you never generate any exception if you use the U
version?
> I am really new to MIPS assembly...
> 
> > assuming that you deliberately want to trap on overflows to detect the
> > stack pointer crossing the user/kernel segment boundary, right?).
>   Not really as explained above ...
> 
> >  NB I suggest that you get real debug information generated as well; it
> > can be stabs if DWARF-2 is too difficult to start with.  The heuristic
> > unwinder is really the last-chance attempt made by GDB to find its way
> > around, can only be relied on when applied to conservative code and is
> > best avoided if possible.
> 
>   But my problem is really that
> GDB found my I do generate stabs debugging information,
> and give parameters and locals
> offsets relative to frame pointer.
> 
> But in mips32_scan_prologue,
> the first
>   ADDI $s8,$sp,LocalSize
> instruction,
>   interpreted it in mips32_scan_prologue function
> but ended up with a wrong position of my
> non-ABI standard frame pointer
> because it changed frame pointer register from sp to s8 register,
> but kept frame_offset value as set by the
>   SUBI $sp, $sp, LocalSize
> instruction
>   analyzed before.
> 
>   Thus GDB wrongly ends up with a
> frame pointer located a
>   value of $s8 register (as from ADDI instruction analysis)
> + LocalSize (from SUBI instruction)
> 
>   This means that of
>   $sp is say at address addr
>   $s8  is at addr +LocalSize
> and the virtual frame pointer
>   $fp at  $s8 + LocalSize = addr + 2 * LocalSize
> 
> 
>   This means that it would be better to remove
> analysis of the ADDI $s8, $sp, LocalSize
> than to leave the current behavior.
> 
>   I think that we should either use my proposed patch,
> or completely remove the analysis of this ADDI $s8, $sp, LocalSize...
> 
> 
> >  I hope this helps, good luck with your port!
> >
> >   Maciej
> 
>   Thanks,
> 
> Pierre