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

[Joel Brobecker <brobecker at adacore dot com>]

Thanks for the detailed feedback :)

>  Thanks for this work -- can you give me a reference to some background 
> information as to why exactly we want to remove the AT_SYMBOL method?

I do not have a specific reference. Only the fact that it's always
been a method that we wanted to deprecate and then remove support for...

>  For the record: the respective ABIs mandate that the stack is aligned
>  to 8 bytes for 32-bit targets and to 16 bytes for 64-bit targets.

Ah, that explains why mips_frame_align aligned to 16 bytes boundaries...
I googled that question instead of looking that information up in my
manuals - my bad.

> There's one fundamental problem with this change -- software breakpoints 
> must not be used unconditionally, because some configurations do not 
> expect or support them.

I think that we will be fine, because the code is not actually inserting
the breakpoint, merely reserving the room for it on the stack. Later
on, the target layer then inserts the breakpoint for us, using the
appropriate method. If you're connected to a board via JTAG, it should
do the right thing.

>  I can address all these microMIPS issues if you like as I'm likely
>  more familiar with that stuff,

I'd feel more comfortable if you did. I think I understand a little
better what you mean by microMIPS, although I thought it was what
the code called mips16. But I realize now that it's something
different, because IIRC you can switch between mips16 and mips32
by simply using odd addresses (or not).

> > @@ -6906,10 +6936,8 @@ mips_gdbarch_init (struct gdbarch_info info, struct gdbarch_list *arches)
> >  
> >    /* MIPS version of CALL_DUMMY.  */
> >  
> > -  /* NOTE: cagney/2003-08-05: Eventually call dummy location will be
> > -     replaced by a command, and all targets will default to on stack
> > -     (regardless of the stack's execute status).  */
> > -  set_gdbarch_call_dummy_location (gdbarch, AT_SYMBOL);
> > +  set_gdbarch_call_dummy_location (gdbarch, ON_STACK);
> > +  set_gdbarch_push_dummy_code (gdbarch, mips_push_dummy_code);
> >    set_gdbarch_frame_align (gdbarch, mips_frame_align);
> >  
> >    set_gdbarch_convert_register_p (gdbarch, mips_convert_register_p);
> 
>  So what if the stack pages are indeed not executable (their page entries 
> have the XI aka Execute Inhibit bit set)?

The only time when we are executing an instruction on the stack is
when the function being called returns and hits the breakpoint.
IIRC, there has been some testing done against this situation,
and things just worked. I suspect that we get a trap, and that trap
correctly gets interpreted. I can see ourselves receiving a signal
instead, but I think this can also be correctly interpreted. Maybe
we'll have to make some adjustement to GDB's core, but I'd rather
fix that if I have a way to reproduce and therefore test...

Cheers,
-- 
Joel