Re:Updating binutils for new MSP430 chips

[mars4zhu <mars4zhu at 163 dot com>]

Good, I know there is the a link script for the 8051 architecture in keil software, and the TI CCStudio has a cmd file as a link script, maybe you can use them as an example
At 2010-08-13 22:53:22ï"Peter Bigot" <pab@peoplepowerco.com> wrote:
>Support for TI's MSP430 line of microcontrollers was added to binutils in
>the mid 2000s, and is most frequently used with the mspgcc project's patches
>to GCC 3.2.3.  I've been maintaining the forked versions used in mspgcc4 for
>the last six months, and have been working with Texas Instruments to extend
>GNU toolchain support to several chip lines that have been added since then.
>I'm now working to bring the mspgcc and mspgcc4 back together and unify the
>toolchain.
>
>I've been unable to contact the listed binutils MSP430 maintainer (Dmitry
>Diky) at any of the email addresses I've found, and he doesn't appear to be
>active in the community.  So I'm planning to proceed with updates.  I'd like
>to do this in a way that they can be integrated into the main distribution,
>but that's secondary to developing a solution that's maintainable.  What's
>there right now doesn't meet that goal.
>
>Currently binutils has two architectures defined for MSP430: EM_MSP430 and
>EM_MSP430_OLD.
>
>Mainline binutils has 14 sub-architectures (bfd_mach_msp*/E_MSP430_MACH_*)
>and 59 emulations.  The forked binutils has 25 sub-architectures with 100
>emulations.
>
>The sub-architectures seem to have no purpose.  Only two are actually used
>for something that can't be represented in an emulation (whether a hardware
>multiply capability is available), and I think that should be a compiler
>multilib feature just as with SIMD instruction support.  I suspect the rest
>were intended to avoid problems when linking object files built for two
>different chips with different register addresses that were resolved at
>assembly time, but in fact there's not even a warning if you actually do
>this.
>
>What I would like to do is eliminate all the distinct architectures.
>There's one architectural extension that added a few instructions, but I'm
>not convinced it warrants a distinct machine type.
>
>Questions:
>
>(a) In what way is the specific machine number used that would cause
>problems if I did this?
>
>(b) Should I be concerned about existing object files and libraries that
>have the current numbers embedded in them?  (If the machine number is never
>used, I think the answer is it won't matter.)
>
>(c) Would eliminating all these machine numbers be an acceptable patch for
>mainline binutils?
>
>Next question deals with emulations.  There are currently over 270 chips in
>the MSP430 line.  Most of them differ in terms of flash and RAM memory
>addresses and sizes, as well as whether certain peripherals are available
>(which isn't a concern to binutils).  Historically, the approach has been to
>define an emulation for each one of them.
>
>What I'd really like to do is have a file for each chip that defines its
>MEMORY section, and possible the physical addresses of the hardware
>registers it supports.  Everything else, such as the SECTIONS blocks, should
>be close to the same.
>
>I would really like to have a way where, if TI releases a new chip that
>requires a different MEMORY command block, a user can add that to a build
>command and use the chip without requiring an update to binutils.  From the
>linker script perspective it seems like this should be possible with -T, and
>possibly other ways.
>
>The killer is the need to list each emulation in ld/Makefile.am.  It's just
>unworkable, and clutters binutils.
>
>I'm wondering whether I can get away with a single emulation for
>elf32msp430, and require that any invocation of ld include as an input a
>script with the appropriate MEMORY command, something like the way elfm64hc*
>does for the GENERIC_BOARD variants.
>
>Question:
>
>(a) What linker configuration architecture you would recommend to solve this
>problem?
>
>Thanks.
>
>Peter