Regenerate config/features/rs6000

Anmol P. Paralkar b07584@freescale.com
Tue Apr 1 20:23:00 GMT 2008


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"/>
   </feature>

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

Thanks,
Anmol.

>
> -- 
> Daniel Jacobowitz
> CodeSourcery
>



More information about the Gdb mailing list