0

My goal is to be able to monkeypatch a lot of my functions when I do a test build, while having regular behaviour for normal builds (linker error).

I know that I can use #pragma weak or __attribute__ (( weak)) in front of the functions I want to monkeypatch in the original module to say to the linker: "this function is monkeypatchable".

But this would destroy the normal behaviour in the regular build. Instead I would like something to put in the new module, like #pragma this_is_the_one_definition. Which would then make the linker choose this definition whatever the next functions and modules he check after.

They are ways around (Set GCC default attribute for all functions (get all function symbol to be weak for monkeypatching)), but it feel wrong from me to do that. Is there really no way to force a linker to stick to one definition? It seem weird to me that this feature would not have been considered doable/usefull, but in the other end the whole weak symbol stuff had been implemented.

ninjaconcombre
  • 286
  • 2
  • 12
  • You can put all object modules with inferior functions into a library, and then link your application statically with it. When building tests, provide your alternate implementation, and the linker will not use the function in the library. – the busybee Jun 24 '20 at 13:57
  • @thebusybee: That typically requires that each affected function be isolated in a translation unit of its own, or that the compiler and linker support separating functions within a translation unit. Otherwise, if any symbol from a translation unit is needed, the linker will take the entire object module it appears in. – Eric Postpischil Jun 24 '20 at 14:14
  • Hey @the busybee. Well this solution looked really appealing to me before the comment of EricPostpischil. Because it looked like something that would work whatever the platform. Did you actually used the method with sucess and know it work in practice? Because I have seen a lot of seen said on internet such what EricPostpischil said and I have seen the opposite as well. – ninjaconcombre Jun 24 '20 at 19:57
  • Well, it all boils down to your architecture and design specification. -- If you want to test some function and need a mock-up of a function of the same translation unit, you have to use such "tricks" like the attribute or special linker options. -- If you can separate all functions into their own translation unit, you could just link the function to test with your test driver that implements all other functions. -- Recently we did it the other way around: Testing modules in their original form, but providing all other needed mocks and stubs by a library. – the busybee Jun 24 '20 at 20:11
  • The worst situation is when all is ready and fixed, and nobody considered testing up-front. That's why professionals strive to design testable architectures. There are tons of books and tutorials about this, because this issue is difficult, and it's far too easy to shoot yourself in the foot. -- My experience is similar as yours: Good designs are rare animals. The dumb stuff is everywhere. -- You might like to try some of the unit-testing frameworks, and learn from their documentation and design decisions. I wrote one for 8-bit microcontrollers (8051), unfortunately it's closed source. – the busybee Jun 24 '20 at 20:16

0 Answers0