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
next prev parent 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