This is the mail archive of the
mailing list for the GDB project.
Re: Regenerate config/features/rs6000
On Tue, 1 Apr 2008, Daniel Jacobowitz wrote:
On Tue, Apr 01, 2008 at 12:07:16PM -0500, Anmol P. Paralkar wrote:
Assume that you are adding support for 'newarch' (say under powerpc).
Why do you even need this?
Only in the instance of a truly brand new architecture?
You should be able to generate the C file
from an existing PowerPC even before teaching it about the new
architecture variant. If that doesn't work then you can't provide
new variants over remote, which would defeat the point. If there was
an error, please let me know.
Sure, yes. That is not a problem e.g. powerpc-603.xml where, I suppose
the variation is indicated by :
<reg name="hid0" bitsize="32"/>
<reg name="rpa" bitsize="32"/>
Meanwhile, I'd love to remove the circular dependency, but I haven't
thought of a way to do it yet.
When you say circular dependency, you mean using a GDB to generate a
part of itself, right? For variants of existing architecures this not
so non-intuitive. However, when adding a brand new arch. (e.g. say if we
had XML descriptions in place and were adding support for the e500),
one has to teach it about the new architecture first, else it's not
going to like the: <architecture>powerpc:e500</architecture> resulting in:
warning: while parsing target description (at line <?>): Target description specified unknown architecture "powerpc:e500"
warning: Could not load XML target description; ignoring
There is no target description to print.
For a situation like that, is there a simpler process than/alternative to
the one I outlined in my previous mail?