Re: [patch/rfc] Don't complain about unknown OSABI

[Andrew Cagney <ac131313 at ges dot redhat dot com>]

> On Tue, Aug 20, 2002 at 12:03:32PM -0400, Andrew Cagney wrote:
>
> >
> > >>GDB uses ../bfd/config.bfd to find the default architecture.  I think 
> > >>this has made our lives much easier -- gdb's and bfd's defaults match 
> > >>and we don't have to maintain anything.  It really is a ``free lunch'' :-)
> > >>
> > >>Is there an equivalent for the OS/ABI?  If we can pick that default up 
> > >>from binutils then we also get that for free.  On the other hand if we 
> > >>start wiring this stuff into configure.tgt (duplicating ld/gcc) we take 
> > >>on an additional maintenance task.
> > >
> > >
> > >Exactly my point.  There is no OS/ABI equivalent; BFD doesn't know what
> > >it is, and doesn't need to.
> > >
> > >I'll try to put this together tomorrow.
>
> No, I won't.  Too much arguing about the interaction with set
> architecture that I didn't find in my inbox till after I said that.
> I'd be willing to put together a version that didn't do that, leaving
> the subtleties for a later hacker, but I expect Andrew wouldn't like
> that very much :)
:-)  There are too many edge cases to leave to later.  More examples:

Here are more examples:

(gdb) thread 1
(gdb) show architecture
mips
(gdb) show osabi
MIPS GNU/Linux
(gdb) thread 2
(gdb) show architecture
x86
(gdb) show osabi
cygwin

or even:

(gdb) show architecture
mips
(gdb) show osabi
n64
(gdb) up
(gdb) show architecture
mips
(gdb) show osabi
o32
(gdb) bt
foo at line 10
<system call>
bar at line 20

(or more bizare, tos in an RPC :-)).

In the past people have got around this by using:
	set/show/info <arch> <command>
eg
	info ppc something
and in so doing, ducked the multi-arch problem.

So I'm guessing:

(gdb) set architecture mips
OSABI cygwin not applicable to MIPS, use <insert default>? (y or n)?

but that could create the problem:

(gdb) set architecture mips
OSABI NS32/NetBSD not applicable to MIPS, use IRIX? (y or n)? n
(gdb) set osabi MIPS/GNU/Linux
OSABI GNU/Linux not applicable to ns32k architecture.

Arrg!

One way round it is:

(gdb) set architecture mips MIPS/GNU/Linux

another would be:

(gdb) set osabi MIPS/GNU/Linux
Current architecture is NS32K, change to MIPS? (y or n)

enjoy,
Andrew






> > Ah, M'kay :-)
> >
> > Next question.  Given an unbranded mips-elf binary, what should the 
> > following GDB's do?
> >
> > gdb
> > m68k-linux-gnu-gdb
>
> Probably complain, unknown architecture.  Yes, I know you mentioned
> that one can do a certain amount of debugging with just an ELF-aware
> GDB.  Not enough that the OSABI ever comes into play, though.
>
>
> > mips-gdb
> > linux-gnu-gdb
> > elf-gdb
>
> These are all exceedingly hypothetical beasts at the moment, so I don't
> know quite what you mean by the "triplet"s.
>
>
> > mips-linux-gnu-gdb
> > mips-netbsd-gdb
>
> Default to Linux, default to NetBSD.
>
>
> > Having the behavour key off the target creates a problem with an 
> > identical executable behaving differently with different, but similar 
> > GDBs.  I suspect it will encourage people to build different GDB's for 
> > identical purposes when just a single GDB is needed.
>
> That's my point though.  I _need_ for a MIPS/Linux GDB to default to
> MIPS/Linux if there's a missing branding.  That's an ease-of-use,
> obviousness-of-use thing.  GDB has to accept that its detection
> mechanisms are sometimes imperfect.  There will be a set osabi command
> of some sort, it now seems, so the user could always override if
> necessary.
>
> Just a single GDB is needed.  But using the right tool for the task, or
> at least a wrapper which sets the right variables for the task...
>
> -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer