2021-03-08 02:25 AM
How is the startup-file generated? As far as I understand, the symbols from the linker-script (_sdata, _edata, _sbss, _ebss and _sidata) are used to copy the ".data" section from the LMA (Flash) to the VMA (RAM), to initialize the ".bss" section with zeroes and to locate the stack. This is done by the "Reset_Handler" function whose start-adress is placed in the ".isr" section. According to the map-file, the code of the "Reset_Handler" function is placed in the ".text" section.
According to my understanding, the labels (adresses) of the linker-file are required to generate the "Reset_Handler" function. After that, the code of the function is placed in the ".text" section of the linker file. But this will change the follwing labels (adresses). So the adresses used for the generation of the startup-file might have changed and the startup-file might be incorrect.
Is ".text" space required for the "Reset-Handler" calculated in advance and reserved when the linker-file is generated? Or is it a kind of iteration process? Which instance of the gcc toolchain generates the startup-file?
Thanks
Andreas
Solved! Go to Solution.
2021-03-08 03:28 AM
Maybe your confusion stems from lack of understanding of the compile-assemble-link process.
Result of compilation and assembling of one particular source file is the so called object file (.o), which contains a chunk of "almost ready" binary code, where the symbols which are external to that particular source (thus have to be "imported") are not yet resolved, i.e. there are zeros in place of them; and also there is a piece of "metadata" (think of a table) in the object file, which descripts the unresolved symbols (their names) and their location in the binary. Also, the binary does not have determined its absolute final position, so the symbols which might be needed by other portions of the completed program (e.g. functions entry points, i.e. "exported symbols") are again contained in another table. The same goes for data which are defined in this source file, both initialized and uninitialized.
The linker then takes these objects, places pieces of binary code after each other (and places pieces of data after each other), calculates the final values of each symbol and replaces the "zeros" in the binary code for these values.
HTH,
JW
2021-03-08 02:44 AM
From my knowledge startup material is end user code / responsability despite if at early begining so proposal is done Thanks STM32Cube.
So being crystal clear no GCC tool is generating material about here
2021-03-08 03:28 AM
Maybe your confusion stems from lack of understanding of the compile-assemble-link process.
Result of compilation and assembling of one particular source file is the so called object file (.o), which contains a chunk of "almost ready" binary code, where the symbols which are external to that particular source (thus have to be "imported") are not yet resolved, i.e. there are zeros in place of them; and also there is a piece of "metadata" (think of a table) in the object file, which descripts the unresolved symbols (their names) and their location in the binary. Also, the binary does not have determined its absolute final position, so the symbols which might be needed by other portions of the completed program (e.g. functions entry points, i.e. "exported symbols") are again contained in another table. The same goes for data which are defined in this source file, both initialized and uninitialized.
The linker then takes these objects, places pieces of binary code after each other (and places pieces of data after each other), calculates the final values of each symbol and replaces the "zeros" in the binary code for these values.
HTH,
JW
2021-03-09 12:52 AM
Startup and linker file, ale created manually, usually you get this files are provided from manufacturer of MCU. This files usually differs by vector table, rest of them is common.
Startup file uses addresses ganerated by linker script,
2021-03-09 03:41 AM
Thank you very much. If I got you right, the time the startup-file is generated, there are no specific adresses associated with the labels procured by the linker. The linker file is created after the startup file, which is handled like "normal" object file.