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

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

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 329 bytes --]

Hello,

The attached patch removes the warning message that is printed when the 
OSABI is unknown (all the sniffers failed).

When debugging an embedded executable, there is no OSABI info.  Hence I 
don't think the warning should be issued.  This can be seen when 
debugging a GCC created, mips-elf executable.

thoughts?
Andrew

[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 901 bytes --]

2002-08-18  Andrew Cagney  <ac131313@redhat.com>

	* osabi.c (gdbarch_init_osabi): Don't complain about an unknown
	ABI.

Index: osabi.c
===================================================================
RCS file: /cvs/src/src/gdb/osabi.c,v
retrieving revision 1.5
diff -u -r1.5 osabi.c
--- osabi.c	27 Jul 2002 01:28:43 -0000	1.5
+++ osabi.c	18 Aug 2002 13:53:49 -0000
@@ -232,13 +232,8 @@
 
   if (osabi == GDB_OSABI_UNKNOWN)
     {
-      /* Don't complain about not knowing the OS ABI if we don't
-	 have an inferior.  */
-      if (info.abfd)
-	fprintf_filtered
-	  (gdb_stderr, "GDB doesn't recognize the OS ABI of the inferior.  "
-	   "Attempting to continue with the default %s settings",
-	   bfd_printable_arch_mach (arch_info->arch, arch_info->mach));
+      /* Don't complain about not knowing the OS ABI.  Assume the user
+         knows what they are doing.  */
       return;
     }
 

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

[Daniel Jacobowitz]

On Sun, Aug 18, 2002 at 11:41:01AM -0400, Andrew Cagney wrote:
> Hello,
> 
> The attached patch removes the warning message that is printed when the 
> OSABI is unknown (all the sniffers failed).
> 
> When debugging an embedded executable, there is no OSABI info.  Hence I 
> don't think the warning should be issued.  This can be seen when 
> debugging a GCC created, mips-elf executable.
> 
> thoughts?
> Andrew

I like it.  I asked for this change about two months ago when I noticed
it on mips-elf.  And there's a typo in the message you're removing,
too.

[On the related hand, we just had some reports about a case where the OS
ABI is isn't detected (on uClibc) - do you think a (configure.tgt based
or *.mt based rather than in a header, I think) way to specify the
default OS ABI based on the target triplet would be appropriate?

Linux kernels do not have ABI tagging, which comes from glibc, but
generally use the Linux OS ABI.]

> 2002-08-18  Andrew Cagney  <ac131313@redhat.com>
> 
> 	* osabi.c (gdbarch_init_osabi): Don't complain about an unknown
> 	ABI.
> 
> Index: osabi.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/osabi.c,v
> retrieving revision 1.5
> diff -u -r1.5 osabi.c
> --- osabi.c	27 Jul 2002 01:28:43 -0000	1.5
> +++ osabi.c	18 Aug 2002 13:53:49 -0000
> @@ -232,13 +232,8 @@
>  
>    if (osabi == GDB_OSABI_UNKNOWN)
>      {
> -      /* Don't complain about not knowing the OS ABI if we don't
> -	 have an inferior.  */
> -      if (info.abfd)
> -	fprintf_filtered
> -	  (gdb_stderr, "GDB doesn't recognize the OS ABI of the inferior.  "
> -	   "Attempting to continue with the default %s settings",
> -	   bfd_printable_arch_mach (arch_info->arch, arch_info->mach));
> +      /* Don't complain about not knowing the OS ABI.  Assume the user
> +         knows what they are doing.  */
>        return;
>      }
>  


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Jason R Thorpe]

On Sun, Aug 18, 2002 at 11:41:01AM -0400, Andrew Cagney wrote:

 > The attached patch removes the warning message that is printed when the 
 > OSABI is unknown (all the sniffers failed).
 > 
 > When debugging an embedded executable, there is no OSABI info.  Hence I 
 > don't think the warning should be issued.  This can be seen when 
 > debugging a GCC created, mips-elf executable.
 > 
 > thoughts?

This has always been kind of a gray area ... There's really an argument
for doing it either way, and the warning in fact came from the ancestors
of the common code ... but, you're probably right that the best overall
solution would be to just remove the warning.

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>

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

[Elena Zannoni]

Andrew Cagney writes:
 > Hello,
 > 
 > The attached patch removes the warning message that is printed when the 
 > OSABI is unknown (all the sniffers failed).
 > 
 > When debugging an embedded executable, there is no OSABI info.  Hence I 
 > don't think the warning should be issued.  This can be seen when 
 > debugging a GCC created, mips-elf executable.
 > 
 > thoughts?

Yes. I am hitting this on powerpc with the e500 port. It also makes
the testsuite fail in some spots. So, I like it.

Thanks.
Elena



 > Andrew
 > 2002-08-18  Andrew Cagney  <ac131313@redhat.com>
 > 
 > 	* osabi.c (gdbarch_init_osabi): Don't complain about an unknown
 > 	ABI.
 > 
 > Index: osabi.c
 > ===================================================================
 > RCS file: /cvs/src/src/gdb/osabi.c,v
 > retrieving revision 1.5
 > diff -u -r1.5 osabi.c
 > --- osabi.c	27 Jul 2002 01:28:43 -0000	1.5
 > +++ osabi.c	18 Aug 2002 13:53:49 -0000
 > @@ -232,13 +232,8 @@
 >  
 >    if (osabi == GDB_OSABI_UNKNOWN)
 >      {
 > -      /* Don't complain about not knowing the OS ABI if we don't
 > -	 have an inferior.  */
 > -      if (info.abfd)
 > -	fprintf_filtered
 > -	  (gdb_stderr, "GDB doesn't recognize the OS ABI of the inferior.  "
 > -	   "Attempting to continue with the default %s settings",
 > -	   bfd_printable_arch_mach (arch_info->arch, arch_info->mach));
 > +      /* Don't complain about not knowing the OS ABI.  Assume the user
 > +         knows what they are doing.  */
 >        return;
 >      }
 >  

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

[Jason R Thorpe]

On Sun, Aug 18, 2002 at 11:49:27AM -0400, Daniel Jacobowitz wrote:

 > [On the related hand, we just had some reports about a case where the OS
 > ABI is isn't detected (on uClibc) - do you think a (configure.tgt based
 > or *.mt based rather than in a header, I think) way to specify the
 > default OS ABI based on the target triplet would be appropriate?

Yah, I think having the default provided by the configury would be a
good idea.

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>

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

[Andrew Cagney]

> On Sun, Aug 18, 2002 at 11:41:01AM -0400, Andrew Cagney wrote:
> 
>> Hello,
>> 
>> The attached patch removes the warning message that is printed when the 
>> OSABI is unknown (all the sniffers failed).
>> 
>> When debugging an embedded executable, there is no OSABI info.  Hence I 
>> don't think the warning should be issued.  This can be seen when 
>> debugging a GCC created, mips-elf executable.
>> 
>> thoughts?
>> Andrew
> 
> 
> I like it.  I asked for this change about two months ago when I noticed
> it on mips-elf.  And there's a typo in the message you're removing,
> too.

> [On the related hand, we just had some reports about a case where the OS
> ABI is isn't detected (on uClibc) - do you think a (configure.tgt based
> or *.mt based rather than in a header, I think) way to specify the
> default OS ABI based on the target triplet would be appropriate?

I know.  Being able to print the OSABI would help (set/show abi).

I think it should ask BFD.  BFD can then go and look at the target 
tuple. That would mean that BFD and GDB are ``on the same page''.   See 
the hacks I've got GDB pulling to figure out the default architecture.

> Linux kernels do not have ABI tagging, which comes from glibc, but
> generally use the Linux OS ABI.]

Andrew

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

[Andrew Cagney]

> Hello,
> 
> The attached patch removes the warning message that is printed when the OSABI is unknown (all the sniffers failed).
> 
> When debugging an embedded executable, there is no OSABI info.  Hence I don't think the warning should be issued.  This can be seen when debugging a GCC created, mips-elf executable.
> 
> thoughts?

All positive, I've checked it in.

Andrew

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

[Daniel Jacobowitz]

On Sun, Aug 18, 2002 at 12:42:18PM -0400, Andrew Cagney wrote:
> >On Sun, Aug 18, 2002 at 11:41:01AM -0400, Andrew Cagney wrote:
> >
> >>Hello,
> >>
> >>The attached patch removes the warning message that is printed when the 
> >>OSABI is unknown (all the sniffers failed).
> >>
> >>When debugging an embedded executable, there is no OSABI info.  Hence I 
> >>don't think the warning should be issued.  This can be seen when 
> >>debugging a GCC created, mips-elf executable.
> >>
> >>thoughts?
> >>Andrew
> >
> >
> >I like it.  I asked for this change about two months ago when I noticed
> >it on mips-elf.  And there's a typo in the message you're removing,
> >too.
> 
> >[On the related hand, we just had some reports about a case where the OS
> >ABI is isn't detected (on uClibc) - do you think a (configure.tgt based
> >or *.mt based rather than in a header, I think) way to specify the
> >default OS ABI based on the target triplet would be appropriate?
> 
> I know.  Being able to print the OSABI would help (set/show abi).

Yes.  Did you look at the patch posted two or three days ago to add
set/show commands?

Actually, as he probably doesn't have copyright papers on file, I may
whip something equivalent together today.

> I think it should ask BFD.  BFD can then go and look at the target 
> tuple. That would mean that BFD and GDB are ``on the same page''.   See 
> the hacks I've got GDB pulling to figure out the default architecture.

This doesn't make sense to me.  The different is that BFD and GDB both
have a notion of architecture; but BFD has no notion of OSABI.  The
distinguishing markers we use come from the system libraries as often
as not.

My suggestion:  First we'd add set/show osabi, with settings for each
(known?  Registered?  I think registered.) OSABI.  Then it would also
have "default" and "auto".  The difference is that auto would use the
detection mechanism and fall back to default if necessary, and default
would be fixed.  Then we'd set the default in one of two ways:

 - Specify the default value in configure.tgt
 - Do some analysis of the target triplet in osabi.c

I'm inclined to go with a list of registered OSABI's, and to set the
default at configure time.  How's that sound?


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Andrew Cagney]

>> I know.  Being able to print the OSABI would help (set/show abi).
> 
> 
> Yes.  Did you look at the patch posted two or three days ago to add
> set/show commands?

Yes, and it is a hard command to implement right (or even figure out 
what implement right even means!).

> Actually, as he probably doesn't have copyright papers on file, I may
> whip something equivalent together today.

Be sure to wear a seatbelt, the problem is harder than it looks.

>> I think it should ask BFD.  BFD can then go and look at the target 
>> tuple. That would mean that BFD and GDB are ``on the same page''.   See 
>> the hacks I've got GDB pulling to figure out the default architecture.
> 
> 
> This doesn't make sense to me.  The different is that BFD and GDB both
> have a notion of architecture; but BFD has no notion of OSABI.  The
> distinguishing markers we use come from the system libraries as often
> as not.

Something in binutils knows what the basic OS is.   The linker often 
knows to brand the executable a certain way (although increasingly it is 
the compiler that is telling the linker everything).  What executable, 
for instance, does:

	as -o s.o /dev/null
	ld s.o

create?

> My suggestion:  First we'd add set/show osabi, with settings for each
> (known?  Registered?  I think registered.) OSABI.  Then it would also
> have "default" and "auto".  The difference is that auto would use the
> detection mechanism and fall back to default if necessary, and default
> would be fixed.  Then we'd set the default in one of two ways:
> 
>  - Specify the default value in configure.tgt
>  - Do some analysis of the target triplet in osabi.c
> 
> I'm inclined to go with a list of registered OSABI's,

It should match against the registered OSABI's.

 > and to set the
> default at configure time.  How's that sound?

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.

Andrew

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

[Jason R Thorpe]

On Mon, Aug 19, 2002 at 07:03:07PM -0400, Andrew Cagney wrote:

 > Something in binutils knows what the basic OS is.   The linker often 
 > knows to brand the executable a certain way (although increasingly it is 
 > the compiler that is telling the linker everything).  What executable, 
 > for instance, does:
 > 
 > 	as -o s.o /dev/null
 > 	ld s.o
 > 
 > create?

binutils doesn't really know this, per se.  Some BFD back-ends plop
an ELF OSABI value into that part of the ELF ID.  But e.g. alpha-netbsd
does not, because there is no OS-specific anything in the BFD back-end.
(I would say the majority of BFD back-ends fall into this category.)

In the above case, GDB would not know the OS ABI for a NetBSD binary,
because the NetBSD ABI tag, which is provided by crtbegin.o, is not
linked into the executable.

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

In BFD, it depends on the back-end.  e.g. if you want a back-end that
sets the ELF OS ABI field to "FreeBSD", the back-end has to be a -fbsd
back-end (are there any in the tree like this now?).

Anyway, I don't think we can rely on BFD to provide us with OS ABI
information (because BFD doesn't actually *know* about OS ABI things
in the same sense that GDB does).

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>

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

[Daniel Jacobowitz]

On Mon, Aug 19, 2002 at 07:03:07PM -0400, Andrew Cagney wrote:
> 
> >>I know.  Being able to print the OSABI would help (set/show abi).
> >
> >
> >Yes.  Did you look at the patch posted two or three days ago to add
> >set/show commands?
> 
> Yes, and it is a hard command to implement right (or even figure out 
> what implement right even means!).
> 
> >Actually, as he probably doesn't have copyright papers on file, I may
> >whip something equivalent together today.
> 
> Be sure to wear a seatbelt, the problem is harder than it looks.
> 
> >>I think it should ask BFD.  BFD can then go and look at the target 
> >>tuple. That would mean that BFD and GDB are ``on the same page''.   See 
> >>the hacks I've got GDB pulling to figure out the default architecture.
> >
> >
> >This doesn't make sense to me.  The different is that BFD and GDB both
> >have a notion of architecture; but BFD has no notion of OSABI.  The
> >distinguishing markers we use come from the system libraries as often
> >as not.
> 
> Something in binutils knows what the basic OS is.   The linker often 
> knows to brand the executable a certain way (although increasingly it is 
> the compiler that is telling the linker everything).  What executable, 
> for instance, does:
> 
> 	as -o s.o /dev/null
> 	ld s.o
> 
> create?
> 
> >My suggestion:  First we'd add set/show osabi, with settings for each
> >(known?  Registered?  I think registered.) OSABI.  Then it would also
> >have "default" and "auto".  The difference is that auto would use the
> >detection mechanism and fall back to default if necessary, and default
> >would be fixed.  Then we'd set the default in one of two ways:
> >
> > - Specify the default value in configure.tgt
> > - Do some analysis of the target triplet in osabi.c
> >
> >I'm inclined to go with a list of registered OSABI's,
> 
> It should match against the registered OSABI's.
> 
> > and to set the
> >default at configure time.  How's that sound?
> 
> 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.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Andrew Cagney]

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

Ah, M'kay :-)

Next question.  Given an unbranded mips-elf binary, what should the 
following GDB's do?

gdb
mips-linux-gnu-gdb
linux-gnu-gdb
m68k-linux-gnu-gdb
mips-netbsd-gdb
mips-gdb
elf-gdb

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.

enjoy,
Andrew

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

[Daniel Jacobowitz]

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

> 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

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

[Jason R Thorpe]

On Tue, Aug 20, 2002 at 12:03:32PM -0400, Andrew Cagney wrote:

 > Next question.  Given an unbranded mips-elf binary, what should the 
 > following GDB's do?
 > 
 > gdb
	"unknown"

 > mips-linux-gnu-gdb
	"GNU/Linux"

 > linux-gnu-gdb
	"GNU/Linux"

 > m68k-linux-gnu-gdb
	"You lose."

 > mips-netbsd-gdb
	"NetBSD ELF"

 > mips-gdb
	"unknown"

 > elf-gdb
	"unknown" assuming there is MIPS support, else "You lose."

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

The target name merely specifies a default.  If they want to force it
to a certain ABI always, they can put "set osabi ..." in their setup
file.

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>

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

[Jason R Thorpe]

On Tue, Aug 20, 2002 at 09:22:02AM -0700, Jason R Thorpe wrote:

 > On Tue, Aug 20, 2002 at 12:03:32PM -0400, Andrew Cagney wrote:
 > 
 >  > Next question.  Given an unbranded mips-elf binary, what should the 
 >  > following GDB's do?
 >  > 
 >  > gdb
 > 	"unknown"

I guess I should qualify this the same way as "elf-gdb" below.

 >  > elf-gdb
 > 	"unknown" assuming there is MIPS support, else "You lose."

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>

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

[Andrew Cagney]

> 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 

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

[Daniel Jacobowitz]

On Wed, Aug 21, 2002 at 01:03:57PM -0400, Andrew Cagney wrote:
> >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:

(I'm still not going to do this but) I don't think it's feasible to
ask that the command handle all these sorts of cases, since the
machinery in GDB isn't present for them.  I don't think we even have a
way to figure out what OS/ABIs are valid for an architecture.  All
arches right now are the same processor family, in any configuration I
know of, and so all registered OS/ABIs are valid for all architectures,
and none of these cases even exist.

Trying to code for edge cases that can't exist yet leads to sloppiness,
in my opinion.  Those cases should be dealt with when we have the means
to build a GDB supporting more than one processor family, and someone
adds per-architecture OS/ABIs.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Jason R Thorpe]

On Wed, Aug 21, 2002 at 01:08:39PM -0400, Daniel Jacobowitz wrote:

 > Trying to code for edge cases that can't exist yet leads to sloppiness,
 > in my opinion.  Those cases should be dealt with when we have the means
 > to build a GDB supporting more than one processor family, and someone
 > adds per-architecture OS/ABIs.

FWIW, I agree 100% with Daniel.

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>

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

[Andrew Cagney]

> On Wed, Aug 21, 2002 at 01:08:39PM -0400, Daniel Jacobowitz wrote:
> 
>  > Trying to code for edge cases that can't exist yet leads to sloppiness,
>  > in my opinion.  Those cases should be dealt with when we have the means
>  > to build a GDB supporting more than one processor family, and someone
>  > adds per-architecture OS/ABIs.

A patch to include more than one architecture into a single gdb was 
posted a year ago :-)

> FWIW, I agree 100% with Daniel.

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

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.

enjoy,
Andrew

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

[Daniel Jacobowitz]

On Wed, Aug 21, 2002 at 04:26:52PM -0400, Andrew Cagney wrote:
> >On Wed, Aug 21, 2002 at 01:08:39PM -0400, Daniel Jacobowitz wrote:
> >
> > > Trying to code for edge cases that can't exist yet leads to sloppiness,
> > > in my opinion.  Those cases should be dealt with when we have the means
> > > to build a GDB supporting more than one processor family, and someone
> > > adds per-architecture OS/ABIs.
> 
> A patch to include more than one architecture into a single gdb was 
> posted a year ago :-)

I know.  I observe that it isn't in yet, either.

> >FWIW, I agree 100% with Daniel.
> 
> 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 :-)

I'd argue (in fact, am arguing) that the user interface will be just
fine with multiple architectures, with the command as discussed, but
that the edge conditions should wait.

> 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 we don't break them down like that.  The OSABI is "GNU/Linux".

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

Sure.  This problem is _EVERYWHERE_ in GDB.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Richard Earnshaw]

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