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

[Daniel Jacobowitz <drow@mvista.com>]

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