1

I'm trying to union many functions so that they will all run in the same small section of ram but be loaded from elsewhere.

I have done this for several sections explicitly with a sections command simmilar to the following:

UNION run = RAM
{
    .text:testFunc:testSHA256_Final: {} load = TESTFUNCTIONS
    .text:testFunc:testSHA256_Final2: {} load = TESTFUNCTIONS
}

But this requires editing the linker command file to include every function that I want to union together. I'd like to be able to do something like:

UNION run = RAM
{
    .text:testFunc: {} load = TESTFUNCTIONS
}

But this of course places all of the input sections into one output section so no unioning takes place.

I also tried

UNION run = RAM
{
    .text:testFunc:*: {} load = TESTFUNCTIONS
}

But that just looked for the literal star and ended up not finding any sections. Is there any way to specify many sections within a union such that the sections will end up overlapping in run space without explicitly identifying them?

I'm using Code Composer Studio to link for a MSP430, but anything would help.

1

While I am not familiar with the tool chain that you are using, in the past, I have seen a mechanism that might help. That is to identify the candidate for any special treatment with any one of:

  • A very specific naming convention
  • A pragma annotation
  • A very specific comment annotation

Any of these will let you automatically generate a list of the candidates for a given special treatment, in your case UNION, using tools such as grep, and generate the linker instructions from a template as a pre-link step. Many scripting languages can be used to produce this but personally I would use python and most tool chains allow you to insert additional build steps.

The things that I would encourage anybody to do when customising the build process:

  • Document it where it can't be missed.
  • Clear errors & halt if parts of the tool chain are missing.
  • Consider using a build system such as make, cmake, scons, ant, etc., that can be invoked from your IDE rather than the IDE built in systems as they are much more likely to survive tool updates.
  • Good version control.
  • Thanks. That was pretty much the route I was headed down, as I already have some pre-build steps. Any particular suggestions for where to place build documentation such that it can't be missed? – Rick Feb 28 '17 at 14:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.