Use weak functions in the RTEMS core?

[Sebastian Huber]

On 08/04/2020 17:57, Jonathan Brandmeyer wrote:

> There are a couple more disadvantages.
>
> Which definition is pulled into the final link depends on the order 
> that the object files are listed on the command-line.  If the weak one 
> is seen first, then the linker will resolve the symbol against the 
> weak definition and it won't even search into subsequent archives for 
> the strong one.  It will merely suppress multiple-definition errors at 
> link time.
>
> We ran into this issue in our project when we over-rode some RTEMS 
> weak symbols in one of our static archives.  Since the dependency 
> graph seen by the linker was from one object in librtems.a to another 
> object in librtems.a, the only way we could reliably pull in our 
> override was by listing our archive as an object to be linked instead 
> of as an archive to be searched (ie, named as libour_runtime.a instead 
> of -lour_runtime on the link step command).

For the linker weak functions are like ordinary functions during the 
symbol resolving phase. If the linker finds the weak one first, then it 
is happy and stops searching. If you encounter problems like this, then 
weak functions are used for the wrong thing.

I would like to use weak functions with one level of indirection. For 
example an application can use two features A and B. Both use an 
interface C. If only A is used, then C can be implemented via D or E. If 
B is used, then C must be implemented via E. For this you can use a weak 
implementation D of interface C in module of A and a strong 
implementation E in module of B.

>
> Additionally, it is not trivial to verify which implementation was 
> actually pulled into the linked object. Tools like `nm` and `objdump` 
> just list the symbol name that ends up in the final ELF.  You have to 
> generate a map file and then examine it to establish which object file 
> provided the resolved symbol.  Maybe this difficulty can be reduced a 
> little with symbol versioning.
Yes, it is a bit more difficult, however, you can resolve it without 
running the application. With global function pointers which change 
values during runtime it is even more complicated to verify.