From: Richard Earnshaw <rearnsha@arm.com>
To: Andrew Cagney <ac131313@ges.redhat.com>
Cc: Jason R Thorpe <thorpej@wasabisystems.com>,
Daniel Jacobowitz <drow@mvista.com>,
gdb-patches@sources.redhat.com, Richard.Earnshaw@arm.com
Subject: Re: [patch/rfc] Don't complain about unknown OSABI
Date: Fri, 23 Aug 2002 06:07:00 -0000 [thread overview]
Message-ID: <200208231240.NAA19807@cam-mail2.cambridge.arm.com> (raw)
In-Reply-To: Your message of "Wed, 21 Aug 2002 16:26:52 EDT." <3D63F78C.4050001@ges.redhat.com>
> Code isn't the problem here. It's the user-gdb interface. Does the the
> user model still work if there is more than one architecture. Not
> exploring the user-gdb interaction and instead just hacking code is how
> we came to have all the CLI querks we've come to hate :-)
>
> Anyway, I suspect just forcing the architecture when the OSABI is
> changed is the most robust approach:
>
> > (gdb) set osabi MIPS/GNU/Linux
> > Current architecture is NS32K, change to MIPS? (y or n)
>
> ``the user is always right'' (no matter how silly it is :-).
But if gdb doesn't know how to handle the user's request, it doesn't
matter how right the user is, they're still going to get garbage out of
the debugger.
> I think it is also becomming aparent that there are several OSABI involved:
>
> - the global default
> - the current instance
>
> ``set osabi'' would change the current instance.
I think if we had the 'sniffer' code work as follows (I forget the names
of the functions, but I think you'll get the drift):
abi = sniff_osabi (abfd, allow_user_override);
if (! handled_by_this_arch (abi))
{
gdb_printf("Don't know how to handle abi '%s' on this architecture, "
"using automatic detection", abi->name);
abi = sniff_osabi (abfd, force_sniff);
}
Then each target arch can decide if it knows how to handle an ABI and if
not force selection.
sniff_osabi would probably do
if (allow_user_override && user_override != automatic)
return user_override;
/* start of auto-sniffer code. */
R.
next prev parent reply other threads:[~2002-08-23 12:41 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-08-18 8:41 Andrew Cagney
2002-08-18 8:49 ` Daniel Jacobowitz
2002-08-18 8:54 ` Jason R Thorpe
2002-08-18 9:42 ` Andrew Cagney
2002-08-19 9:15 ` Daniel Jacobowitz
2002-08-19 16:03 ` Andrew Cagney
2002-08-19 16:15 ` Jason R Thorpe
2002-08-19 18:55 ` Daniel Jacobowitz
2002-08-20 9:03 ` Andrew Cagney
2002-08-20 9:11 ` Daniel Jacobowitz
2002-08-21 10:04 ` Andrew Cagney
2002-08-21 10:08 ` Daniel Jacobowitz
2002-08-21 10:11 ` Jason R Thorpe
2002-08-21 13:26 ` Andrew Cagney
2002-08-21 13:38 ` Daniel Jacobowitz
2002-08-23 6:07 ` Richard Earnshaw [this message]
2002-08-20 9:22 ` Jason R Thorpe
2002-08-20 9:25 ` Jason R Thorpe
2002-08-18 8:51 ` Jason R Thorpe
2002-08-18 8:52 ` Elena Zannoni
2002-08-18 11:01 ` Andrew Cagney
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=200208231240.NAA19807@cam-mail2.cambridge.arm.com \
--to=rearnsha@arm.com \
--cc=Richard.Earnshaw@arm.com \
--cc=ac131313@ges.redhat.com \
--cc=drow@mvista.com \
--cc=gdb-patches@sources.redhat.com \
--cc=thorpej@wasabisystems.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