binutils porting to new CPU

binutils porting to new CPU

[Ralph Escherich]

Hi,

I wanted to port the gnu gcc and binutils to a new cpu architecture. Searching
on the web revealed, that cgen should be able to generate all necessary 
modifications for the binutils portion from a single cpu description file.

Searching through the cgen mailing list, I was able to get cgen running. It
generates appropriate files in the binutils/opcode directory, but nothing 
else.

My research on the web shows, that for a complete port of the binutils
to a new cpu the follwing parts have to be modified/created:


Basically you will need to create these files.  (Replace FOO with the
name of your chip):

  gas/config/tc-FOO.h           - Customisation of generic parts of the 
assembler
  gas/config/tc-FOO.c           - Port specific parts of the assembler
  include/{coff|elf}/FOO.h      - Port specific header file
  include/opcodes/FOO.h         - Port specific ISA encoding
  opcodes/FOO-dis.c             - Port specific disassembler routines
  opcodes/FOO-opc.c             - Port specific ISA encoding
  bfd/{elf32|coff}-FOO.c        - Port specific relocation handlers
  bfd/cpu-FOO.c                 - Port specific description of the CPU
  ld/scripttempl/FOO.sc         - Port specific linker template file
  ld/emulparam/FOO.sh           - Port specific linker customisation

You will also need to add support for your chip to the various
configuration files:

  gas/configure.in
  opcodes/configure.in
  bfd/configure.in
  bfd/config.bfd
  bfd/archures.c
  bfd/reloc.c
  ld/configure.in
  ld/configure.tgt
  include/dis-asm.h

So my basic questions: 
1.) Is cgen supposed to do all the above changes, file generations?
2.) If not all, what does it generate and how can it really be used?

Esche

Re: binutils porting to new CPU

[Frank Ch. Eigler]

Hi -

> [...]
> My research on the web shows, that for a complete port of the binutils
> to a new cpu the follwing parts have to be modified/created:
> [...]
>   include/opcodes/FOO.h         - Port specific ISA encoding
>   opcodes/FOO-dis.c             - Port specific disassembler routines
>   opcodes/FOO-opc.c             - Port specific ISA encoding

These are the only files generated by cgen for binutils, but you'll
notice that these are the primary ones that contain the most complex
aspects for supporting target processor.

The others need to be built by hand.  Of these, only the
bfd/{*}-FOO.c file has given me particular headaches, having to
represent object file relocations in a clunky way.  (This part
motivated Red Hat to build a reusable generic relocation engine
for a particularly peculiar & reconfigurable target.  This code
has not been made public though AFAIK.)


- FChE

Re: binutils porting to new CPU

[Ralph Escherich]

Hi,

Thanks for the explanation. I took a closer look at the output files
(always a good idea before asking more questions :-). 
I can identify an API that seems to be used for the assembler
instruction parsing part. There are a lot of other api parts  
where I can not really identify what they are used for
 
Do you have a more detailed API description of what is generated and
how it should be used for porting the binutils? If not, could you maybe 
provide me with enough information. I would volunteer to  write it up
as a howto, together with my experience of the porting job.

Also gas/cgen.c contains code for fixups and parsing. How does all
this fit into the big picture of porting binutils to a new cpu target?

How do fixups and frags ??? fit into the API?

Sorry for asking those basic porting questions, but I'm trying to 
get the big picture, so that I can determine how to tackle
the porting task best.



Esche

On Tuesday 28 October 2003 18:48, Frank Ch. Eigler wrote:
> Hi -
>
> > [...]
> > My research on the web shows, that for a complete port of the binutils
> > to a new cpu the follwing parts have to be modified/created:
> > [...]
> >   include/opcodes/FOO.h         - Port specific ISA encoding
> >   opcodes/FOO-dis.c             - Port specific disassembler routines
> >   opcodes/FOO-opc.c             - Port specific ISA encoding
>
> These are the only files generated by cgen for binutils, but you'll
> notice that these are the primary ones that contain the most complex
> aspects for supporting target processor.
>
> The others need to be built by hand.  Of these, only the
> bfd/{*}-FOO.c file has given me particular headaches, having to
> represent object file relocations in a clunky way.  (This part
> motivated Red Hat to build a reusable generic relocation engine
> for a particularly peculiar & reconfigurable target.  This code
> has not been made public though AFAIK.)
>
>
> - FChE

Re: binutils porting to new CPU

[Frank Ch. Eigler]

[-- Attachment #1: Type: text/plain, Size: 1269 bytes --]

Hi -


>  [...]
> Do you have a more detailed API description of what is generated and
> how it should be used for porting the binutils? [...]

There isn't a really good list, I'm afraid.  None of those who have
built a complete port took the extra time to document all the steps
and nuances.  It's all rather vernacular: start based on an existing
port, do a massive search & replace for a new port name, ask here when
you run into trouble.  A simple port may go smoothly enough not to
need any help.


> Also gas/cgen.c contains code for fixups and parsing. How does all
> this fit into the big picture of porting binutils to a new cpu target?

It's a necessary detail.  The fewer addressing modes your target supports,
and the simpler the layout of the operands that parametrize any given
address, the simpler (to almost nonexistent) these functions can be.


> How do fixups and frags ??? fit into the API? [...]

They barely do.  Some CGEN operand parsing functions plop fixups into
the assembler, for ultimate disposition as an assembly-time constant,
or emission as a link-time relocation.  Frags are little
partially-filled-in byte strings that are concatenated ultimately
to form object code.  All this is deep GAS/BFD magic, not really cgen
related.


- FChE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: binutils porting to new CPU

[Ralph Escherich]

I tried building binutils-2.14 for the openrisc-elf target and get the 
following error message:

openrisc-asm.c: In function `openrisc_cgen_assemble_insn':
openrisc-asm.c:584: error: `CGEN_INSN_RELAX' undeclared (first use in this 
function)
openrisc-asm.c:584: error: (Each undeclared identifier is reported only once
openrisc-asm.c:584: error: for each function it appears in.)
make[3]: *** [openrisc-asm.lo] Error 1

openrisc-asm.c was generated by cgen

Any ideas??

Esche

On Wednesday 29 October 2003 08:50, Frank Ch. Eigler wrote:
> Hi -
>
> >  [...]
> > Do you have a more detailed API description of what is generated and
> > how it should be used for porting the binutils? [...]
>
> There isn't a really good list, I'm afraid.  None of those who have
> built a complete port took the extra time to document all the steps
> and nuances.  It's all rather vernacular: start based on an existing
> port, do a massive search & replace for a new port name, ask here when
> you run into trouble.  A simple port may go smoothly enough not to
> need any help.
>
> > Also gas/cgen.c contains code for fixups and parsing. How does all
> > this fit into the big picture of porting binutils to a new cpu target?
>
> It's a necessary detail.  The fewer addressing modes your target
> supports,
> and the simpler the layout of the operands that parametrize any given
> address, the simpler (to almost nonexistent) these functions can be.
>
> > How do fixups and frags ??? fit into the API? [...]
>
> They barely do.  Some CGEN operand parsing functions plop fixups into
> the assembler, for ultimate disposition as an assembly-time constant,
> or emission as a link-time relocation.  Frags are little
> partially-filled-in byte strings that are concatenated ultimately
> to form object code.  All this is deep GAS/BFD magic, not really cgen
> related.
>
>
> - FChE

-- 
Ralph Escherich                               2900 Gordon Avenue Suite 203
Senior IC Design Engineer                     Santa Clara, CA 95051-0718
Phone:  408-328-9333
Fax:    408-735-1163

http://www.mobilesmartsinc.com

Re: binutils porting to new CPU

[Ben Elliston]

Ralph Escherich <esche@mobilesmartsinc.com> writes:

> I tried building binutils-2.14 for the openrisc-elf target and get
> the following error message:

Wasn't the openrisc port abandoned?

Ben

Re: binutils porting to new CPU

[Ralph Escherich]

Not from what I read on opencores.org.
Anyway, its just an example I wanted to use to get started.
I've got the same problem for other architectures.

I guess the binutils do not match the cgen I got.

Esche

On Wednesday 29 October 2003 17:53, Ben Elliston wrote:
> Ralph Escherich <esche@mobilesmartsinc.com> writes:
> > I tried building binutils-2.14 for the openrisc-elf target and get
> > the following error message:
>
> Wasn't the openrisc port abandoned?
>
> Ben

Re: binutils porting to new CPU

[Ben Elliston]

Ralph Escherich <esche@mobilesmartsinc.com> writes:

> I guess the binutils do not match the cgen I got.

Are you using latest sources for both from CVS?

Ben

Re: binutils porting to new CPU

[Ralph Escherich]

> Are you using latest sources for both from CVS?
No, I'm using binutils-2.14. For cgen I'm using the latest CVS snap.
I couldn't get the scheme code going with release 1.0.

The binutils do not come with cgen included, not even the CVS snapshots
posted on the FTP site.

BTW. I seems you where right. The openrisc in the official release is not 
named openrisc, but or32. (checked last night) So its probably old stuff I'm 
looking at.

Which CPU port would be an easy one to get started with?

Esche

Re: binutils porting to new CPU

[Ben Elliston]

Ralph Escherich <esche@mobilesmartsinc.com> writes:

> No, I'm using binutils-2.14. For cgen I'm using the latest CVS snap.
> I couldn't get the scheme code going with release 1.0.

You should use CVS binutils if you're using CVS cgen.

> Which CPU port would be an easy one to get started with?

fr30 is probably a nice case.

Ben