This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]