STM32F4 Weird Disassembly output - Page 1
Forum section: electronics / general

author: SolarSunrise
author_rank: Regular Contributor
timestamp: June 08, 2014, 12:46:16 pm
content: 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!

author: dannyf
author_rank: Super Contributor
timestamp: June 08, 2014, 01:30:43 pm
content: QuoteYes, if the compiled code doesn't work;No, otherwise.

author: AlfBaz
author_rank: Super Contributor
timestamp: June 08, 2014, 03:06:25 pm
content: 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

author: mrflibble
author_rank: Super Contributor
timestamp: June 08, 2014, 03:45:22 pm
content: Also, you can pass the-Wl,--gc-sectionsoption to gcc to get rid of unused symbols. With that you can see which symbols are actually being used.

author: westfw
author_rank: Super Contributor
timestamp: June 09, 2014, 05:11:14 am
content: 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.

author: AlfBaz
author_rank: Super Contributor
timestamp: June 09, 2014, 07:35:41 am
content: 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 functionThe 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

author: andersm
author_rank: Super Contributor
timestamp: June 09, 2014, 08:54:29 am
content: Quote from: AlfBaz on June 09, 2014, 07:35:41 amYou 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.QuoteThe 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.