This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [ping] Re: [Patch] arch recognition fix for osabi.c
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Mark Kettenis <kettenis at chello dot nl>
- Cc: kewarken at qnx dot com, gdb-patches at sources dot redhat dot com
- Date: Fri, 11 Jul 2003 12:32:27 -0400
- Subject: Re: [ping] Re: [Patch] arch recognition fix for osabi.c
- References: <08c201c334e6$ccb8c750$0202040a@catdog> <20030617155147.GA25280@nevyn.them.org> <08d801c334ea$23fd99c0$0202040a@catdog> <20030619190853.GA25755@nevyn.them.org> <113c01c347bd$ba454a00$0202040a@catdog> <200307111626.h6BGQi3W033834@elgar.kettenis.dyndns.org>
On Fri, Jul 11, 2003 at 06:26:44PM +0200, Mark Kettenis wrote:
> From: "Kris Warkentin" <kewarken@qnx.com>
> Date: Fri, 11 Jul 2003 11:04:29 -0400
>
> Mark, Daniel had suggested that you were the end of the line as far as
> approving this change.
>
> Thread starts here:
> http://sources.redhat.com/ml/gdb-patches/2003-06/msg00562.html
>
> Hmm, I folloed that thread, and I have some things to say about it. I
> just never did :-(.
>
> The code is deliberately written the way it is. The idea is that for
> each CPU architecture we have a number of processors. Some of these
> are compatible with each other. Others aren't. The trick is to find
> the ISA that is most compatible. Most processor families out there
> are backwards compatible, which basically means that a new processor
> is based on ISA of its predecessor and adds some functionality to
> that. For processor families that work like that,
> bfd_default_compatible does the right thing, and the code in
> gdbarch_init_osabi selects an OSABI/ISA that's a subset of the desired
> ISA.
>
> Apparently this doesn't work for MIPS, since BFD declares different
> processors (which it calls "machines") to be incompatible. I'm not
> quite familiar with MIPS, but I suppose this is not quite true, but
> that the various MIPS processors cannot be mapped on a one-dimensional
> quantity that expresses the features of the various CPU's. That could
> be a valid reason why the MIPS "compatibility function" is written the
> way it is. Perhaps it can be improved? If so, I think that's the way
> to go. Otherwise, I think you should register for all CPU types that
> you support.
It doesn't declare different machines to be incompatible. Take another
look at mips_compatible; it is actually more lenient than the default.
But it _always_ returns a, and osabi.c expects it to return b. I
suppose that we could change mips_compatible to return the subset type
if one has mach == 0. But even the default doesn't do that right now.
> One could argue that if one registers a handler for the "default
> machine" that this should apply for all machines within an
> architecture, but that breaks down for architectures that support both
> 32-bit and 64-bit machines.
Which is why the word size is checked separately in
bfd_default_compatible. mips_compatible is a whole other kettle of
worms.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer