This is the mail archive of the
mailing list for the binutils project.
Re: Supporting more than one CPU with the same gas port.
What I believe Sean is specifically asking about is in relation to
Freescale embedded microcontrollers that have two distinct CPUs within
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
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
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.
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.