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

[Andrew Cagney <ac131313@ges.redhat.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