Supporting more than one CPU with the same gas port.
nick clifton
nickc@redhat.com
Thu Jan 5 10:55:00 GMT 2012
Hi James,
> What I believe Sean is specifically asking about is in relation to
> Freescale embedded microcontrollers that have two distinct CPUs within
> them.
> The main processor is a CISC device (S12X)
> The second processor is a RISC device (XGATE)
>
> So, within one microcontroller there are two processors that use
> different machine code. However, they share common RAM and peripherals
> and the XGATE code starts off in the same flash space as the S12X code.
OK, but why do you want one toolchain that can handle both types of
processor, rather than two toolchains, one for each processor ?
I get that you might want to include binaries for both types of
processor into a single executable image, but you can already do this
with the existing tools. (Eg the .incbin directive in gas or the
--add-section option to objcopy). In fact it seems to me that the
easiest way to do this might be to treat the executables for the
secondary processor as overlays and use the linker's overlay mechanism
to handle them.
> My belief is that this works, given a caveat
> - you have to know which target the code was assembled for when
> disassembling it and where in memory it is located.
>
> gas and objdump use the CPU specific target
> ld uses the m68hc12elf (shared) target
But this is basically the same as having two toolchains, one for the
S12X and one for the XGATE. In fact the only issue I see with the two
toolchain approach comes when trying to disassemble an executable that
contains code for both processors. (Actually I imagine that there would
also be an issue when trying to debug such a binary, but that is outside
the scope of this discussion). You could use --section option to
objdump to restrict disassembly to only those sections relevant to the
toolchain being used, although this is rather clunky.
> I felt that the linking together (sharing external variables) was a
> benefit outweighing the perhaps unconventional approach.
Which presumably you can do with the toolchain for the S12X processor,
provided that it has been configured to allow the XGATE processor as an
additional target.
So the real problem is that although you can use the S12X toolchain for
most things, you cannot use it to assemble or disassemble XGATE
binaries. For that you need a second toolchain, or else a combined
toolchain that really is combined, including GAS and OBJDUMP. Which was
the point of this whole thread. Ok - so I see where you are coming from
now.
Have you considered treating the XGATE architecture as a variant of the
S12X architecture, in the same way as THUMB/ARM or MIPS16/MIPS ? I am
sure that they are actually wildly different, but what if you pretended
that they are not. GAS is perfectly happy with supporting multiple
variants of the same architecture and you could use a feature like the
mapping symbols used by the ARM port to indicate when a section of code
was in S12X or XGATE format.
> thoughts?
Well my main objection is that I am trying to avoid feature bloat (and
hence increased scope for the introduction of bugs). If it is possible
to achieve what you want without extending the tools, then that would be
the option that I would prefer.
Cheers
Nick
More information about the Binutils
mailing list