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