Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <ac131313@cygnus.com>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: RFA: MIPS ABI selection
Date: Sun, 09 Jun 2002 13:19:00 -0000	[thread overview]
Message-ID: <3D03B85D.8050605@cygnus.com> (raw)
In-Reply-To: <20020609192840.GA13703@nevyn.them.org>

> -- 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?

I don't expect this to happen.  As you point out, the 
mips_find_abi_section() makes this all somewhat redundant.

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

My understanding of the purpose of the patch was to change the default 
ABI to O32.  Given that won't always be correct, I think a user command, 
(rather than a source code change) is needed to handle the edge conditions.

> 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.

Check how ``set endian big'' works or the ABI mechanism in the CRIS 
target.  It forces an architecture update with just one field set.  The 
rest of the architecture information still being taken from the previous 
architecture.

> -- 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.

I think GDB should be able to rely on build and run-time information 
provided by BINUTILS (bfd/config.bfd, ...) when making this selection. 
I'm also puzzled as to why it was included in the patch.

> _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.

Right!

> 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)?

You mean:

#ifdef MIPS_DEFAULT_ABI
    ..
#else
    if (not set)
       set to O32;?
#endif

My problem is that I know it is going to break something.  Hence the 
need to be able to force the ABI at runtime with a command.

Andrew



  reply	other threads:[~2002-06-09 20:19 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-08 20:20 Daniel Jacobowitz
2002-06-09 12:15 ` Andrew Cagney
2002-06-09 12:32   ` Daniel Jacobowitz
2002-06-09 13:19     ` Andrew Cagney [this message]
2002-06-09 12:37   ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3D03B85D.8050605@cygnus.com \
    --to=ac131313@cygnus.com \
    --cc=drow@mvista.com \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox