Mandatory linking of all modules in a library in CodeWarrior HCS12(X) v4.6

[admin]

Does anybody know how to force the Smart Linker to link all modules inside a library file?
 
Tha manual says:
 
    you need only to specify a '+' after the name of the module in the NAMES block:
 
    NAMES
       myFile1.o+ myFile2.o+ start.o ansi.lib
    END

which works for the individual modules but it does not seem to work if you do:
 
    NAMES
      myLib.lib+ start.o ansi.lib
    END
 
i.e. the mandatory linking doesn't seem to apply to the modules in the library.
 
I am specifically trying to force the linking of all modules in "ansisf.lib".
 
Can anybody shed some light on this?

[admin]

Thanks for the info - I suspected that there was an issue with the linker but couldn't track it down in the documentation.

The reason why I want to link the whole library:

The MC9S12A512 is programmed by our students here at the University of Technology, Sydney. They get to program a custom control algorithm to control things in the lab. They are provided with a complete "framework application" which does all the usual stuff like sample the ADCs, talk to a PC via USB etc. All they have to do is come up with a control algorithm that transforms inputs to outputs (e.g. state variables, fuzzy logic, etc.) To simplify and speed-up the uploading of their algorithms, I have dedicated the Flash at 0x4000 to them. The rest of the application sits in Flash from 0xC000, which is where the runtime libraries also live. If they don't happen to use say FADD.o for floating-point addition, then the smart linker will remove that module from the link operation and "move all other modules down in memory". That means, for example, that FSUB.o is in a different place for a "student link" compared to a "my link".

I need the linker to include all the modules so that all subroutines that the students may use are sitting in memory at known fixed addresses.

The ROM library method would probably also have the same linker issue.

If anyone can think of a better way, I'd be interested to hear...

Thanks.

PMcL

Message Edited by PMcL on 2007-05-15 02:30 PM

[CrasyCat]

Hello

Not sure I understand why you want the _FSUB function to reside always at the same location.

Linker should be able to resolve relocation and call the appropriate function.

Am I missing something here? Why is it important that student have _FADD linked to their application when they do not need it?

Or are you linking and burning the framework separately in flash?

CrasyCat

[admin]

Hi,

Yes, the "framework" is burned separately into Flash at 0xC000 and "should" last forever. The students then come along, write a single function in C, "Make" the entire project (which has a framework library) and then the PC program picks out the locations in the S19 file that reside in Flash 0x4000 and only downloads that to the chip (so it very fast downloading). The speed of downloading was pretty much the only reason it was done this way.

The problem arises when the student function does not use some of the runtime library modules, such as _FSUB, and therefore modules like _FADD are placed by the linker at a new location. So the code at 0x4000 may be calling the _FADD function at 0xE120 when it really is at 0xE269 for example. I need the modules to be static in terms of their address for the "student make" so the modules line up with what is already there in Flash.

For now I've solved the problem just by adding dummy code in the framework that calls on the library modules that I suspect the student's will use (such as _FADD, _FSUB etc.)

I will give the ENTRIES * END way a go...

Thanks for your help.

PMcL

[CompilerGuru]

ROM Libraries sound like a pefect match to your setup.
They are completely linked (say all addresses are resolved) and are supposed to be burned into a ROM separately from the rest of the application.

However there is currently also a problem with them too, AFAIK debug information is not supported for two ELF files at once, and a ROM library is a separate ELF file.
So you either see the debug information for the main app, or the debug information for the ROM library. However you dont see both at once :smileysad:.

How long does it take to download the complete application?
As long as this optimization does make sense?

Daniel

[CrasyCat]

Hello

Do not try ENTRIES * END. This will link all the library functions to the application (including string function stdio, ...) and is not the solution here.

I have to get further though on that but in my opinion best was here is that you define a ROM library for the framework, where you enumerate all the functions that MUST be in there and then student just link the ROM library to their application.

This might be worth a try.

CrasyCat

[CrasyCat]

Hello

Why on earth do you want to link all modules from the ANSI library to your application?

This will take a huge amount of memory and will not really be useful. It will just eat up memoyr for nothing...

CrasyCat

Message Edited by J2MEJediMaster on 2007-05-11 10:25 AM

[CompilerGuru]

I have to agree with CrazyCat that linking all from the ANSI lib looks like a bad idea to start with.

The initial issue is actually known and mentioned in the release note.
out of Release_Notes\HC12\Notes_Linker.txt

>List of known Limitations
>- ELF: The + syntax to disable smart linking is only supported for object files,
>not for complete libraries.

You could extract all the objects files from the library with the libmaker and then link all of them with the + syntax. Well, would work, but not recommended.

Daniel

[CrasyCat]

Hello

Only alternative I know is to disable smart linking for the whole application (this should include files from libraries).

This is done adding the following to your .prm file:

ENTRIES

  *

END

But once again I cannot imagine why someone would need to do that :smileysad:

CrasyCat