STM32F4 Weird Disassembly output

[SolarSunrise]

I decided to give the ST's STM32F4 Standard Peripheral Library a try today and I found bunch of strange sections in the disassembly output like __do_global_dtors_aux, frame_dummy, _mainCRTStartup, memset, etc. Searching google did not help at all.

Where did these sections come from? Are they obligatory? When I wasn't using the ST library I did not get these sections in the disassembly. Is my complier screwed up somehow?

Thanks in advance!

[dannyf]

Is my complier screwed up somehow?

Yes, if the compiled code doesn't work;

No, otherwise.

[AlfBaz]

Firstly the compiler is not bringing that stuff in, the linker is.
Secondly you'll find most of those sections don't come from the peripheral libraries but from precompiled object files namely from things such as libc or libgcc or what ever they're called.

Unless you recompile these "standard" libs, who's source files you probably don't have, there's a good chance that if you call one function in those libs the linker will drag in a heap of other stuff required for the function you called. _mainCRTstartup for example probably initialises a bunch of stuff in one of the above mentioned libs. dtors and ctors are names given to destructor and constructor functions. In a C contect they probably just allocate/de-allocate memory for use by a function or group of funtions

[mrflibble]

Also, you can pass the -Wl,--gc-sections option to gcc to get rid of unused symbols. With that you can see which symbols are actually being used.

[westfw]

It's pretty common for the compiler to stick every function in its own "section" these days.  This enables the linker to omit them if they're not referenced from elsewhere, which is what the "-Wl,--gc-sections" option does.

[AlfBaz]

Maybe somebody can help me recollect this properly but I seem to remember that --gc-sections is not the panacea a lot of people think it is.

If a bunch of functions are included in the one file, the compiler will create one object file for it and if one function is used within it the linker will include all of the fucntions in that file(module scope?), wether they're used or not. I think that's why for a lot of source distro's you see so many files, usually one file for each function

The compiler itself is able to strip unused code as part of it's optimisation but libraries are already compiled so it can't do anything there

[andersm]

Maybe somebody can help me recollect this properly but I seem to remember that --gc-sections is not the panacea a lot of people think it is.

If a bunch of functions are included in the one file, the compiler will create one object file for it and if one function is used within it the linker will include all of the fucntions in that file(module scope?), wether they're used or not. I think that's why for a lot of source distro's you see so many files, usually one file for each function

You have to use the -ffunction-sections to place each function in a separate section for the section garbage collection to be effective. The -fdata-sections does the same for data. Adding all those sections do grow the object files quite a bit, and slows down the build process, which is why you may not want to do it in large projects.

The compiler itself is able to strip unused code as part of it's optimisation but libraries are already compiled so it can't do anything there

The compiler can only strip dead code from within functions, or symbols with static linkage. It can't know if a globally visible symbol is accessed from some other source file. The linker can build a dependency tree for all referenced symbols and use that to remove unused code or data.

EDIT: The "one function per file" thing was relevant for older linkers, which would include code from static libraries with object-file granularity.