porting GCC & GCC backends

[Dave Korn]

On 26 September 2006 20:01, max blomme wrote:

> I'm attempting to port GCC to our companys 32bit microprocessor, and I'm
> a bit overwhelmed.
> 
> Looking through some of the documentation (there's quite a lot of it!) I
> can't seem to find the answers to a few questions.  Pardon me if they
> seem basic and obvious.
> 
> We already have an assembler and linker for the processor.  Should I (or
> can I) use them as the back end of GCC?  

  Yes, you can.  Gcc is designed to interoperate with system-native toolchains
whereever possible.

> If I do use them, can I use the
> GCC debugger (or binutils or wherever the debugger that is tied to GCC is)?

  If your code outputs standard debugging info in dwarf/coff/aout format,
probably.

> If I cannot use our current assembler & linker, is there any
> documentation for porting GAS (I've looked and I can't seem to find any)?

  Build binutils from source, cd into the docs dir and "make internals" should
generate "internals.info", which you could view by "info
--file=internals.info"; it's not build and installed by default.  (It may be
if you use --enable-maintainer-mode when configuring, I don't know).

> The processor has a relocateable object loader in it's internally ROMed
> BIOS which I'd prefer to use, but it's a proprietary format that, as far
> as I know, does not conform to any previous standard.  The loader is
> extendable, buy bootstrapping in another loader.
> 
> In the port for GAS, can I describe this format?  Or do I need to write
> a back end to convert it's output to our format, or write another loader?

  You need to extend the bfd library to understand it.  That's going to be a
nuisance.

> If I'm posting to the wrong list, please point me to the correct one.

  Most of this stuff is low-level toolchain rather than compiler-specific, so
the binutils list might be more informative for a good deal of it.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....