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

[Daniel Jacobowitz <drow at mvista dot com>]

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