This is the mail archive of the 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: 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 :

  <feature name="603">
    <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?


-- Daniel Jacobowitz CodeSourcery

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