Re: [RFA 1/2] mips: Switch inferior function calls to ON_STACK method.

["Maciej W. Rozycki" <macro@codesourcery.com>]

On Tue, 8 May 2012, Joel Brobecker wrote:

> > You set bp_addr to SP here, so you rely on the stack pointer to have
> > been implicitly adjusted down below the current frame [...]
> 
> I was actually confused, as I thought that SP pointed to the first
> unused slot in the stack.

 Correct, but stack grows downwards.  So SP points to the end of the first 
unused slot.  This is best shown with an illustration, e.g. for 32 bits:

       |           | +12
       +           + 
       |   . . .   |  +8
       +           +
       |  current  |  +4
       +           +
       |   frame   |   0
SP --> +-----------+
       |   free    |  -4
       +           +
       |   . . .   |  -8
       +           +
       |           | -12

For example for a nested o32 function at SP + 0 you'll have the next 
frame's $a0 argument save slot.

 This is really no different to how some architectures with hardware stack 
support interpret the SP register, e.g. Intel pieces like 8080 or x86 or 
DEC VAX.

> I will make the changes that you suggest and re-test.

 Great!

> One thing that just occured to me while driving home is why not
> also use the AT_ENTRY_POINT approach. I figured that there must
> have been a reason why we used AT_SYMBOL instead of AT_ENTRY_POINT.
> But then, there is your comment that makes me think that the symbol
> isn't usually defined, which means that most of (all?) the time,
> we actually end up using AT_ENTRY_POINT. Do we know of any reason
> why AT_ENTRY_POINT would not work? I'd assume that as long as the
> object format is ELF, we'd have one, and so we could use that as
> well.

 I mentioned that in one of the replies -- there was a comment originally 
that stated that AT_ENTRY_POINT wouldn't work if it was located in a ROM.  
With software breakpoints that is, but support for hardware breakpoints is 
not mandatory in MIPS processors (and I think we don't use them for 
internal breakpoints anyway).  The comment was removed with the addition 
of AT_SYMBOL.  Presumably that magic symbol would be arranged by a ROM 
image generation toolkit.  As I say, I've never actually encountered it.

> Geee, are we ever going to reach a conclusion on this discussion? :-/

 Well, we'll die off eventually, so certainly there's some finite limit.

  Maciej