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

[Andrew Cagney <ac131313@ges.redhat.com>]

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