Re: RFA: MIPS ABI selection

[Daniel Jacobowitz <drow@mvista.com>]

I have some comments about this reply, but please read all the way
down; most of the comments are academic curiousity.

On Sun, Jun 09, 2002 at 03:15:16PM -0400, Andrew Cagney wrote:
> >The current state of the world in GCC says: a handful of setups default to
> >unique ABIs, but the global default is O32.  The default is also to pass no
> >ABI flags to the assembler.
> >
> >elf64.h, iris6.h, isa3264.h, and r3900.h override this.  Irix defaults to
> >N32 and passing -n32 which presumably tags binaries; plus the irix
> >configuration in GDB can handle this.  elf64.h does not do pass any flags
> >but defaults to O64.  isa3264.h defaults to MEABI and appears not to tag
> >binaries.  r3900.h defaults to EABI and untagged binaries.
> >
> >That's mipsisa32-*-elf*, mips64*-*-elf*, mipstx39*-*-elf*,
> >mips-sgi-irix5cross64, and mips-sgi-irix6*.
> >
> >So what's a debugger to do?  Right now, we try to infer things from our
> >header files, but only little details of the ABI.  In particular, we never
> >infer O32 correctly.  Better would be to match GCC; that's quite
> >straightforward.
> 
> 
> >I skipped mipsisa32-*-elf*, because GDB doesn't support MEABI.  So this
> >patch fixes the defaults for mips64*-*-elf* and mipstx39*-*-elf*, and a
> >little tweaking for IRIX.  It then adds a global O32 default.  In the
> >process I found another way that GCC tags binaries with their ABI: a
> >".mdebug.abi32", etc. section.  I handle that too.  All appears to work 
> >like
> >a charm.  We even get warnings for MEABI etc. binaries.
> >
> >Andrew, this look OK?
> 
> Hmm, this contains several changes:
> 
> 
> -- The function mips_find_abi_section() that better identifies the ABI.
> 
> Yes.  This is definitly a good idea and approved.

I'll commit it separately in a moment.


> -- Adding the macro MIPS_DEFAULT_ABI to all MIPS targets.
> 
> Remember, all the mips/tm-*.h files are going away so this isn't really 
> going to help.  Instead, I think a ``(gdb) set mips abi <tab>.. auto o32 
> ...'' command would be far more useful.  Another place the code could 
> look is the ABI from the previous architecture.

That paragraph is three things:
tm-*.h files are going away:  Yes, certainly, and when they do they
will become OSABIs presumably.  Those new places don't exist yet.  When
they do the default ABI should go in them, and for now I want to put it
in the right place so that it will be picked up and moved over when the
time is right.  What's wrong with that?

"set mips abi": Certainly it's useful, but I'd say it was completely
unrelated to the purpose of my patch.

ABI from the previous architecture: I don't want to do that.  I believe
that generating a new architecture should be completely independent of
the previous architecture.  If we figured it out the first time we can
figure it out again.

> -- Some additional MIPS targets
> 
> Er, we're trying to get the number of MIPS targets down to zero.

GCC supports configuring for those targets.  Binutils supports
configuring those targets.  In both cases they get a special default
ABI that doesn't match GDB's.  I think that makes the new targets quite
justified.

_HOWEVER_: After I commit the bit to use ".mdebug.abi*" sections, we
will always get the ABI for GCC-produced binaries correct, at least as
far back as I can find GCC releases.  After that point I no longer care
what the default case says.  How about I just commit the part which
says "if no tm- file overrides this, default to O32" and the bit which
removes the default case (which accesses a lot of target macros, ew)?

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer