2

I'm currently investigating the possibility to force the rvct compiler not to link in specific translation units and just pretend that it has linked it.

Our product is running very tight on space constraints and have trouble integrating some unit tests with it while keeping the space under control.

Basically, the memory we can leverage during run time is more than sufficient to store our unit tests, but we don't have sufficient rom space to hold them.

We have means to control exactly which segment of memory of our code goes in on our device in the scatter file, so we're thinking along the lines of defining which region the unit test codes will be located and somehow force the compiler not to link in that specific code during compile time.

Something like the following:

Result UnitTestEntryPoint (UnitTest suite) {
   if (hasTestInMemory) {
      switch (suite) {
          case EncrpytionTest:
              return EncrptyUnitTest();
          // more tests.
      }
   }
}

// Actual Tests, can we not link this code, but just pretend we link to them?
Result EncrpyUnitTest (void) {
    // Do stuff...
}

Then during runtime, we'll upload the unit test binaries to the specified memory region that we define in the scatter file, and flip the hasTestInMemory to true.

Is this possible?

Or if not, can someone point me to the right direction of looking for a solution that somehow meets our space constraint and able to load unit tests during run time.

Thanks,

Jimmy Lu
  • 4,810
  • 7
  • 25
  • 30
  • does your platform support libraries like linux libraries (so) ? – MOHAMED Nov 07 '12 at 15:03
  • unfortunately, dynamic loading doesn't seem to be possible as our product is a boot rom and is pretty much the first thing the device loads. – Jimmy Lu Nov 07 '12 at 15:06
  • 1
    Can you build against an alternate set of files which contain only stub implementations? Or #ifdef out the invocations, and use linker options to strip unused code? – Chris Stratton Nov 07 '12 at 15:34
  • If we ifdef out the caller code, the code size will decrease as we no longer invoke the unit test functions anymore. But, how would we invoke them later on during runtime without the caller code? – Jimmy Lu Nov 07 '12 at 15:39
  • Are you looking for weak references? http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0474h/CACCEEIF.html – unixsmurf Nov 07 '12 at 17:26
  • Have you tried overlays? DUI0206 has a description of the linker file. – starblue Nov 07 '12 at 19:43
  • @starblue Overlays seem to be for limited ram size systems. In our case, we have abundant ram but very limited rom size. – Jimmy Lu Nov 07 '12 at 20:08
  • Then you can just tell the linker to put it in RAM. – starblue Nov 07 '12 at 21:18
  • @starblue then the device is switched off and everything is gone... Unless he has persistent RAM o.O – RedX Nov 07 '12 at 22:47
  • Linking and loading it on the device are two different stories. The OP wants to load it himself during runtime. So linking it to a RAM area will be fine, then somehow separate the flash and the RAM parts for the different loading procedures. – starblue Nov 08 '12 at 07:30

1 Answers1

3

You should be able to use your scatter file to place all your unit test functions into a separate load region. When you link your image you'll get one AXF but when you convert it into a binary file for loading into memory you should get two files, one for each region.

You can also have some marker in the unit test image that your ROM image can check for to verify that the binary is loaded. This check would replace your hadTestInMemory check in your code. Again you should be able to place some specific RO data at the beginning of the second binary file using your scatter file.

I can probably help out with some more details as you progress.

Pete Fordham
  • 2,278
  • 16
  • 25
  • Hi, I'm not sure I know what this AXF file is... We've always only had one binary file produced. I followed your advice and put the unit test .o files into a different load region in the scatter file. The produced bin file was smaller than the constraints (about the same size as one without unit tests). But the unit test code is nowhere to be found. – Jimmy Lu Nov 07 '12 at 19:34
  • A second binary file should have been created which will contain the unit tests. I've just corrected my answer to say load regions rather than execution regions, I think that's why you only got one file. – Pete Fordham Nov 07 '12 at 20:49
  • The AXF file is generated by armlink. It's an ELF file containing the load regions. Typically you'd use fromelf to convert this into one or more binary files. – Pete Fordham Nov 07 '12 at 20:51
  • Thanks, I used fromelf and did obtain two separate binaries. – Jimmy Lu Nov 07 '12 at 22:18