* binutils porting to new CPU
@ 2003-10-29 2:20 Ralph Escherich
2003-10-29 2:48 ` Frank Ch. Eigler
0 siblings, 1 reply; 10+ messages in thread
From: Ralph Escherich @ 2003-10-29 2:20 UTC (permalink / raw)
To: cgen
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
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: binutils porting to new CPU
2003-10-29 2:20 binutils porting to new CPU Ralph Escherich
@ 2003-10-29 2:48 ` Frank Ch. Eigler
2003-10-29 16:37 ` Ralph Escherich
0 siblings, 1 reply; 10+ messages in thread
From: Frank Ch. Eigler @ 2003-10-29 2:48 UTC (permalink / raw)
To: Ralph Escherich; +Cc: cgen
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
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: binutils porting to new CPU
2003-10-29 2:48 ` Frank Ch. Eigler
@ 2003-10-29 16:37 ` Ralph Escherich
2003-10-29 16:50 ` Frank Ch. Eigler
0 siblings, 1 reply; 10+ messages in thread
From: Ralph Escherich @ 2003-10-29 16:37 UTC (permalink / raw)
To: Frank Ch. Eigler; +Cc: cgen
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
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: binutils porting to new CPU
2003-10-29 16:37 ` Ralph Escherich
@ 2003-10-29 16:50 ` Frank Ch. Eigler
2003-10-30 0:29 ` Ralph Escherich
0 siblings, 1 reply; 10+ messages in thread
From: Frank Ch. Eigler @ 2003-10-29 16:50 UTC (permalink / raw)
To: Ralph Escherich; +Cc: cgen
[-- 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 --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: binutils porting to new CPU
2003-10-29 16:50 ` Frank Ch. Eigler
@ 2003-10-30 0:29 ` Ralph Escherich
2003-10-30 1:53 ` Ben Elliston
0 siblings, 1 reply; 10+ messages in thread
From: Ralph Escherich @ 2003-10-30 0:29 UTC (permalink / raw)
To: Frank Ch. Eigler; +Cc: cgen
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
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2003-10-31 4:25 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-10-29 2:20 binutils porting to new CPU Ralph Escherich
2003-10-29 2:48 ` Frank Ch. Eigler
2003-10-29 16:37 ` Ralph Escherich
2003-10-29 16:50 ` Frank Ch. Eigler
2003-10-30 0:29 ` Ralph Escherich
2003-10-30 1:53 ` Ben Elliston
2003-10-30 5:46 ` Ralph Escherich
2003-10-30 6:43 ` Ben Elliston
2003-10-30 16:47 ` Ralph Escherich
2003-10-31 4:25 ` Ben Elliston
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).