This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Unclear, where replacement of the _auto_init function during the compilation/linking process takes place.

Other Parts Discussed in Thread: MSP430F1611

I want examine relocation entries from binary data (ELF files) to perform my own relocation subsequently.

Because of the replacement of the __auto_init function I run into trouble.

The startup routine _c_init00_noargs_noexit calls either _auto_init or _auto_init_hold_wdt for auto initialization (with or without watchdog timer) which also depends on the target mcu.

But when I examine the corresponding source and object file (boot_special.c, boot_special.obj) it seems like _auto_init is always called.

Using the readelf tool I get the following relocation entries for the library function _c_init00_noargs_noexit (boot_special.obj): 

The third relocation entry seems to belong to the _auto_init function.

Also within the source code (boot_special.c) the call "_auto_init()" just belongs to the normal _auto_init function defined in autoinit.c.

 

When compiling my program for the target mcu msp430f1611 I get the following disassembly:

Now, _auto_init_hold_wdt  is called and it seems for me as if the _auto_init symbol was magically replaced with _auto_init_hold_wdt.

I cannot understand where the replacement of the symbols took place. Maybe after the compilation process by the linker?

I could find also other symbol replacements  (mspabi_mpyi ->__mspabi_mpyi_hw_mspabi_mpyl ->__mspabi_mpyl_hw) depending if the target mcu has a certain hardware support or not.

Many thanks in advance, 

Felix

  • These symbols are special. The linker does some optimizations with them when certain conditions are met. For instance, the compiler never generates calls to the hardware multiply functions, it always calls __mspabi_mpyi. If you use the --use_hw_mpy option, the linker will rewrite reloctions to __mspabi_mpyi so that they are now relocations to one of the hardware functions. In a similar way, relocations to _auto_init are rewritten as relocations to _auto_init_hold_wdt, etc. Then, normal relocation happens and you see the updated references in the disassembly.
  • Many thanks for your answer!
    So there is really no way to see if __auto_init will be overwritten in the object file but only in the resulting executable?
    In "MSP430 Optimizing C/C++ Compiler" (slau132k.pdf) I read that --use_hw_mpy is now a compiler option and  hardware multiply functions will be inlined by the compiler. But maybe it is still not visible in a precompiled library if a hardware function was used or not?

  • Correct; you can't tell from the object file whether the relocation will be rewritten, and in the executable file, all traces of the fact it was rewritten are gone.

    The current behavior of the hardware multiplication functions are different. If you use the right set of options, small hardware multiply routines will be completely inlined by the compiler, and you just won't get a call in the object code. Some hardware operations (64x64, for instance) are not inlined, so you'll still see some link-time rewriting.

    You should be able to see from the build attributes whether an object file has inlined any hardware multiplication operations. See build attribute tag HW_MPY_INLINE_INFO
  • Thanks a lot! Do you know whether there are other symbol replacements besides of _auto_init and the two multiplication operations? Or can I find a complete list somewhere?
  • I don't know of any off the top of my head. No, there's no comprehensive list. It's not strictly necessary to perform these rewrites; it's just an optimization when we know the library is the TI RTS. You can add your own symbol rewrites in the linker command file, so you might find these in other projects or linker command files for other libraries.