Fix for unit test build on Windows machines

[michalpasztamobica]

Description

When building unit tests on windows a linker error is reported when linking EthernetInterface test, claiming that EthernetInterface::get_target_default_instance() is undefined. This is caused by MinGW not supporting weak attribute.

The changes address this issue using preprocessor macro to determine that minGW is being used. MinGW will only be used in case unit tests are built on windows, as every other compilation will run a target compiler (either ARM or target GCC) or a Unix GCC (both on Linux and Mac).

I checked that target code builds fine on Windows and that unit tests are compiling and running on Linux.

Pull request type

[x] Fix
[ ] Refactor
[ ] Target update
[ ] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change

[0xc0170]

I assume we might have a problem with other functions as well. So applying this only to EthernetInterface method is short term fix.

This is caused by MinGW not supporting weak attribute.

Is it? Isn't this related how gcc defines attribute weak ? I believe it works for elf or .out . What do we generate with Mingw ? Can you provide reference?

[michalpasztamobica]

Sorry, you are right, it is the Windows executable that does not support weak, here's the reference:

"Weak symbols are supported for ELF targets, and also for a.out targets when using the GNU assembler and linker."

I agree that the weak attribute is heavily used in mbedOS source code, but we usually compile to target binaries, which are not Windows executables. The only situation I came across when we compile into a Windows executable is when we we try to run unit tests on Windows. I fixed the only compilation error that was being thrown in this situation.

I can think of a more general change inside platform/mbed_toolchain.h:

#ifndef MBED_WEAK
#if defined(__ICCARM__)
#define MBED_WEAK __weak
+ #elif defined(__MINGW32__)
+ #define MBED_WEAK 
#else
#define MBED_WEAK __attribute__((weak))
#endif
#endif

On one hand it makes sense, but on the other, maybe it is wise to stick to the less-intrusive fix?

[0xc0170]

On one hand it makes sense, but on the other, maybe it is wise to stick to the less-intrusive fix?

This might seem now, but once we have more unittest coverage - more weak problems - we would end up having this exception in more files. I would rather have it in one place with a proper commit.

``

• #elif defined(MINGW32)
• #define MBED_WEAK
  ``

Looks fine to me.

I could not find anything that could support weak linkage in MinGW thus unit test should have this as limitation - all symbols are strongly linked (at least for windows).

@ARMmbed/mbed-os-core Please review

[deepikabhavnani]

This might seem now, but once we have more unittest coverage - more weak problems - we would end up having this exception in more files.

I would prefer a generic solution in platform/mbed_toolchain.h: then per file basis. A quick grep in mbed-os\features\netsocket folder itself showed me multiple instances of MBED_WEAK

cellular/generic_modem_driver/OnboardCellularInterface.cpp:67:MBED_WEAK CellularBase *CellularBase::get_target_default_instance()
cellular/generic_modem_driver/OnboardCellularInterface.cpp:74:MBED_WEAK CellularBase *CellularBase::get_target_default_instance()
emac-drivers/README.md:86:    MBED_WEAK EMAC &EMAC::get_default_instance()
emac-drivers/TARGET_Freescale_EMAC/kinetis_emac.cpp:598:MBED_WEAK EMAC &EMAC::get_default_instance() {
emac-drivers/TARGET_NUVOTON_EMAC/numaker_emac.cpp:396:MBED_WEAK EMAC &EMAC::get_default_instance() {
emac-drivers/TARGET_NXP_EMAC/TARGET_LPC546XX/lpc546xx_emac.cpp:592:MBED_WEAK EMAC &EMAC::get_default_instance() {
emac-drivers/TARGET_NXP_EMAC/TARGET_LPCTarget/lpc17_emac.cpp:968:MBED_WEAK EMAC &EMAC::get_default_instance() {
emac-drivers/TARGET_RZ_A1_EMAC/rza1_emac.cpp:11:MBED_WEAK EMAC &EMAC::get_default_instance() {
emac-drivers/TARGET_Silicon_Labs/sl_emac.cpp:708:MBED_WEAK EMAC &EMAC::get_default_instance() {
emac-drivers/TARGET_STM_EMAC/stm32xx_emac.cpp:573:MBED_WEAK EMAC &EMAC::get_default_instance()
EthernetInterface.cpp:24:MBED_WEAK EthInterface *EthInterface::get_target_default_instance()
EthernetInterface.cpp:30:MBED_WEAK EthInterface *EthInterface::get_target_default_instance()
NetworkInterfaceDefaults.cpp:28:MBED_WEAK EthInterface *EthInterface::get_default_instance()
NetworkInterfaceDefaults.cpp:33:MBED_WEAK WiFiInterface *WiFiInterface::get_default_instance()
NetworkInterfaceDefaults.cpp:38:MBED_WEAK MeshInterface *MeshInterface::get_default_instance()
NetworkInterfaceDefaults.cpp:43:MBED_WEAK CellularBase *CellularBase::get_default_instance()
NetworkInterfaceDefaults.cpp:54:MBED_WEAK WiFiInterface *WiFiInterface::get_target_default_instance()
NetworkInterfaceDefaults.cpp:60:MBED_WEAK NetworkInterface *NetworkInterface::get_default_instance()
NetworkInterfaceDefaults.cpp:74:MBED_WEAK NetworkInterface *NetworkInterface::get_target_default_instance()
NetworkInterfaceDefaults.cpp:79:MBED_WEAK NetworkInterface *NetworkInterface::get_target_default_instance()
NetworkInterfaceDefaults.cpp:106:MBED_WEAK NetworkInterface *NetworkInterface::get_target_default_instance()
NetworkInterfaceDefaults.cpp:111:MBED_WEAK NetworkInterface *NetworkInterface::get_target_default_instance()
NetworkInterfaceDefaults.cpp:141:MBED_WEAK NetworkInterface *NetworkInterface::get_target_default_instance()

[cmonr]

I too would like to see a more generic fix, but I'm wondering something.

@michalpasztamobica @SeppoTakalo Is this PR needed to unblock some new things in CI, or something similar?

I agree that this seems like there will be more issues down the road once more unittest are added, but I'm wondering if we aren't doing some premature optimization in suggesting to solve the problem in a generic manner.

Thinking out loud. Would bringing this PR in, along with opening a new issue to find a more generic solution be a good path forward for all opinion-holders?

[deepikabhavnani]

If issue is blocking CI, then yes I am fine with merging the PR for now with new issue

[michalpasztamobica]

I tested that the change in platform/mbed_toolchain.h works just as good as my previous, more scattered yet less intrusive fix. I also checked that the target compilation is unaffected (including no crashes at runtime) and that unittests compile and run fine on Linux.
The fix is much neater now, in my opinion.

This issue was not blocking the whole CI. It was blocking unittests on Windows. I guess most developers use Unix, but even those who use Windows should run a unittest suite before committing anything, so we'd better have it ready for them to use.

[michalpasztamobica]

@SeppoTakalo , please review.

[0xc0170]

Someone from @ARMmbed/mbed-os-core please review

[0xc0170]

/morph build

[0xc0170]

@michalpasztamobica One thing - is there anywhere we should document this? I assume with unittest you would not rely on weakly linkage, just making sure this can be captured in the docs somewhere or is that clear to everyone?

[michalpasztamobica]

Nothing comes to my mind really... @SeppoTakalo - is there any relevant documentation where we should take a note of this change?

[mbed-ci]

Build : SUCCESS

Build number : 3465
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/8526/

Triggering tests

/morph test
/morph export-build
/morph mbed2-build

[mbed-ci]

Test : SUCCESS

Build number : 3256
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/8526/3256

[mbed-ci]

Exporter Build : SUCCESS

Build number : 3088
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/8526/

[SeppoTakalo]

This probably becomes evident for whoever is going to write the Unittest.

Unittest writing requires so much more knowledge than what has been written in the documentation, so adding this causes more questions than what it answers. So I'm OK for leaving it unmentioned.