OBJECT Keyword Linker

[Rocko]

I'm trying to use the OBJECT keyword to put main of main.c at a known location.  From the CF v5.0 Targeting Manual.  I have the following (simplified)

.text2 :
   {
       OBJECT (main, main.c)
   } > prog_rom

I get the following warning:

                                  Linker command file warning at line 41
                                  Object "main" not found in file "main.c"

The map file shows # text2 is empty

Please can someone highlight what I'm doing wrong or provide a better way of fixing the location of the main function?

Also there is a note in CF v5.0 Targeting Manual  

"When using C++, you must specify functions by thier mangled names"

What does this mean?

Thanks

R

[CrasyCat]

Hello

In fact the Coldfire compiler adds a _ prefix to the name of exported symbols.

So you have to write:

.text2 :
   {
       OBJECT (_main, main.c)
   } > prog_rom

CrasyCat

[Rocko]

Thanks CrasyCat!

Can I do this for _main or is it a special case?

R

[CrasyCat]

Hello

Well as far as I know you have to do it for all symbols with external scope (i.e. all symbols which are not static).

I am not sure if you need to do it also for static objects.

Just as an additional tip. To detect which is the linkage (or internal) name the compiler or assembler is assigning to a symbol:

  - Click with the right mouse button on the source file name in the.mcp window.
  - In the pop up menu select "Disassemble"
  - You will see a new window with disassembly listing.
  - Look at the Symbol Table there and search your function (or variable name).
   You will see the actual linkage name in the symbol table.

If you are building in C++, you will also see the real object name there  

CrasyCat

[J2MEJediMaster]

Sorry I can't help you on your first question. As for C++ mangled names, here's an explanation. OOP languages such as C++ let you override the behavior of an existing function, perhaps to add some capabilities you need. That's the beauty of OOP. However, this override mechanism also has its ugly side. When the linker goes to reference a function name, what is it supposed to do with two functions of the same name, the original function, plus the one you wrote to add the new features? To avoid name collisions that would confuse the dickens out of the linker, the compiler "mangles" the function names so that they are different. Look at the linker map output to see what the managled names are, and use those names in your code.

---Tom