Regenerate config/features/rs6000

Regenerate config/features/rs6000

[Michael Eager]

How are the C files generated from the xml files?

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: Regenerate config/features/rs6000

[Daniel Jacobowitz]

On Mon, Mar 31, 2008 at 04:58:15PM -0700, Michael Eager wrote:
> Daniel Jacobowitz wrote:
>> On Mon, Mar 31, 2008 at 04:01:13PM -0700, Michael Eager wrote:
>>> How are the C files generated from the xml files?
>>
>> It's described in the comments in features/Makefile (you have to set
>> CFILES and use a specific target).
>
> Apparently, there's a circular dependency:  you have to have
> build a gdb so you can generate the feature file which is needed
> to build gdb.

Yes, there is.  You've got to add XML support separately from
requiring the C precompiled features.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Regenerate config/features/rs6000

[Anmol P. Paralkar]

On Mon, 31 Mar 2008, Daniel Jacobowitz wrote:

> On Mon, Mar 31, 2008 at 04:58:15PM -0700, Michael Eager wrote:
>> Daniel Jacobowitz wrote:
>>> On Mon, Mar 31, 2008 at 04:01:13PM -0700, Michael Eager wrote:
>>>> How are the C files generated from the xml files?
>>>
>>> It's described in the comments in features/Makefile (you have to set
>>> CFILES and use a specific target).
>>
>> Apparently, there's a circular dependency:  you have to have
>> build a gdb so you can generate the feature file which is needed
>> to build gdb.
>
> Yes, there is.  You've got to add XML support separately from
> requiring the C precompiled features.
>
> -- 
> Daniel Jacobowitz
> CodeSourcery
>

Hello,

  I recently tried this out; perhaps the following sketch helps:

  Assume that you are adding support for 'newarch' (say under powerpc).

  First, "declare" newarch to GDB:

  bfd/archures.c
  .#define bfd_mach_ppc_newarch    newarchval

  bfd/bfd-in2.h
  #define bfd_mach_ppc_newarch    newarchval

  bfd/cpu-powerpc.c
  const bfd_arch_info_type bfd_powerpc_archs[] =
  {
   ...
     &bfd_powerpc_archs[<index of the <newarch> bfd_arch_info_type that you are adding>]
   },
    {
     32, /* 32 bits in a word */
     32, /* 32 bits in an address */
     8,  /* 8 bits in a byte */
     bfd_arch_powerpc,
     bfd_mach_ppc_<newarch>,
     "powerpc",
     "powerpc:<newarch>",
     3,
     FALSE, /* not the default */
     powerpc_compatible,
     bfd_default_scan,
     NULL
   },
  }

  gdb/rs6000-tdep.c

  static struct variant variants[] =
{
    ...
    {"<newarch>", "PowerPC <newarch>", bfd_arch_powerpc,
    bfd_mach_ppc_<newarch>, NULL /* For now this is NULL. we'll change this after we generate gdb/features/rs6000/powerpc-<newarch>.c */,
    ...
}

  Build GDB. Create gdb/features/rs6000/<newarch>.xml

  We are now ready to generate <newarch>.c from <newarch>.xml

  Use the newly built GDB (at this stage you should be able to do a: 'set architecture powerpc:<newarch>' and see the effect with a: 'show architecture').

  cd gdb/features

  gmake GDB=<prefix>/bin/powerpc-linux-gnu-gdb XMLTOC="./rs6000/powerpc-<newarch>.xml" ./rs6000/powerpc-<newarch>.c

  If all goes well, you should have gdb/features/rs6000/powerpc-<newarch>.c now.

  Go back to gdb/rs6000-tdep.c

#include "features/rs6000/powerpc-<newarch>.c"

...

  static struct variant variants[] =
{
    ...
    {"<newarch>", "PowerPC <newarch>", bfd_arch_powerpc,
    bfd_mach_ppc_<newarch>, &tdesc_powerpc_<newarch>,  /* Note! */
    ...
}

...

void
_initialize_rs6000_tdep (void)
{
  ...
  initialize_tdesc_powerpc_<newarch> ();
  ...
}

  That should be it. You should now be able to: 'set tdesc filename <?>/gdb/features/rs6000/<newarch>.xml' ...

Regards,
Anmol.

Re: Regenerate config/features/rs6000

[Daniel Jacobowitz]

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

Meanwhile, I'd love to remove the circular dependency, but I haven't
thought of a way to do it yet.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Regenerate config/features/rs6000

[Anmol P. Paralkar]

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
>

Re: Regenerate config/features/rs6000

[Daniel Jacobowitz]

On Tue, Apr 01, 2008 at 03:22:05PM -0500, Anmol P. Paralkar wrote:
>> 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),

The e500 is not a brand new architecture, as far as GDB is concerned.
It's what I was calling a variant.  It's adding XML support to a new
foo*-* target that's really awkward.

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

I see.  All you need to add before you can do this is the BFD bits;
you shouldn't need to add it to GDB's list, but PowerPC might be
special in this regard.

-- 
Daniel Jacobowitz
CodeSourcery