Undefined symbols in final output

[MichaelAtSamraksh]

Please check tinyclr.dump for arm-none-eabi-nm output, or execute

%GNU_TOOLS_BIN%\%GNU_TARGET%-nm.exe -u %SPOCLIENT%\BuildOutput\THUMB2\%COMPILER_TOOL_VERSION%\le\FLASH\debug\EmoteDotNow\bin\tinyclr.axf

The following functions are called but do not exist in the final binary:

_Z25DATASTORE_REG_RemoveEntryPv possibly called from DeviceCode\pal\Samraksh\DataStore\Datastore.cpp:1465

_ZN15HALTimerManager12DeInitializeEv possibly called from DeviceCode\Targets\Native\STM32F10x\DeviceCode\drivers\advancedtim\netmf_advancedtimer.cpp:40

arm_rfft_q31 called from Solutions\EmoteDotNow\TinyCLR/tinyclr.cpp:175 arm_cfft_radix4_init_q31 arm_cfft_radix4_q31 arm_float_to_q31 arm_q31_to_float arm_rfft_init_q31

SD_LowLevel_DeInit called from DeviceCode\Targets\Native\STM32F10x\DeviceCode\drivers\sdio\stm32_eval_sdio_sd.c:213

Disclaimer: I did not attempt to backtrace beyond where these are called to see if they matter. A code coverage tool could indicate whether these are ever reached... (which would change the bug to unreachable code paths wasting storage).

                  ___
                  _-_-  _/\______\\__
               _-_-__  / ,-. -|-  ,-.`-.
                  _-_- `( o )----( o )-'
                         `-'      `-'
---~--~------
////////////|
\\\\\\\\\\\\\
/////////////
\\\\\\\\\\\\|
////////////|
\\\\\\\\\\\\|

[Nathan-Stohs]

This is in current master? It still all links right? At a glance it looks to me like these functions are all dead code, e.g. not reachable from main(), and so pruned at link time from the final binary by ( by --gc-sections I think ) and so never generates a link error.

In of itself, it is not a bug and is totally innocuous. It would not increase binary size and the clutter impact on the code is negligible.

However while we're on the topic of pruning... such pruning DOES have implications for the external static library / DLL user. If any of these functions were meant to be available for them, and were so pruned, that would be a bug. Here I believe that is either not the case or the argument is very weak.

Mike, how did you determine this to begin with? Does nm directly tell you or did you have to do some extra processing?

Because of the external static library / DLL user issue, we will likely have to disable pruning and fill in these functions. Or we keep pruning enabled and make this check with nm a test and verify that no external facing functions are culled.

Action: Bug staying open to gather any additional comments. I will take some action to ensure at least the TimerManager bit from the list above is not culled. Otherwise pruning will stay on for now but I think it likely we will determine later that it should be off.

[Nathan-Stohs]

My determination is that this isn't really a bug, but good to know. Closing.

[AnishAtSamraksh]

Nathan,

I assume we are leaving the dead code in.

Can we get a sense of the extent of dead code overall to see if it's worth our effort in pruning?

With best wishes, Anish

On Jul 10, 2014, at 7:00 PM, "Nathan Stohs" notifications@github.com<mailto:notifications@github.com> wrote:

My determination is that this isn't really a bug, but good to know. Closing.

Reply to this email directly or view it on GitHubhttps://github.com/Samraksh/MF/issues/158#issuecomment-48675642.

[Nathan-Stohs]

Anish, the case here is that the dead code is already removed from the binary before programming. This is done automatically by the tools, so I don't think there is much benefit to be had.

In any case, from Mike's list, we are looking at a handful of small functions and it would not necessarily be a good idea to prune them. For example one of the functions Mike listed is the Time_Deinit() function. This is dead code because practically speaking there is no set of conditions for MF to stop keeping time, yet it is part of the PAL spec and it seems reasonable to keep such code around.