Re: [RFC] Mips, N32, cc, gcc, and gdb (longish)

[Andrew Cagney <ac131313@ges.redhat.com>]

> Daniel Jacobowitz wrote:

>> > > > This of course makes gdb's behavior dependent on which
>> > > > compiler it detects.
>> > > >
>> > > > There is one problem: there is no variable "gcc_p" within
>> > > > the scope of mips_push_arguments, because PUSH_ARGUMENTS
>> > > > does not pass it.  So that would need to be solved,
>> > > > possibly by modifying the definition of PUSH_ARGUMENTS.
>> > > >
>> > > > Comments?
> 
>> > >
>> > > Comment - you're on a slippery slope.  I know of at least one other
>> > > variation in this area; for structures of less than a word SGI CC
>> > > shifts them in register only for big endian targets, and not for little
>> > > endian (on the old versions of CC which support little endian).  There
>> > > comes a point where we just need to get GCC fixed, and I think this is
>> > > it.
> 
>> >
>> > Right -- but this thread concerns what to do if that DOESN'T happen.
>> >
>> > In answer to your comment, I believe the code currently in GDB
>> > already handles the case you describe, both for CC and for GCC.
>> > So what I'm discussing here will bring stack-passing into line
>> > with register-passing.
>> >
>> > However, you may be right that I need to check for endian-ness
>> > in my proposed change.  I haven't tested that.
> 
>> 
>> I'm not actually sure if it's the same if statement. 
> 
> 
> It's not.
> 
> 
>> Certainly GDB and GCC do not agree on mipsel-linux.
>> 
>> I'd say the proper thing to do is to see that GCC is fixed, not to lay
>> contingency plans...
> 
> 
> Well then, I hope somebody else replies!   ;-)

I hope it wasn't me :-)

GCC need to be fixed.  Either they need to define a new abi that 
specifies all their breakage OR they fix it to match the offical abi.  I 
have a sinking feeling that they'll do both.

Andrew