https://sourceware.org/bugzilla/show_bug.cgi?id=31921
Nick Clifton <nickc at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |nickc at redhat dot com
--- Comment #1 from Nick Clifton <nickc at redhat dot com> ---
Hi Christoph,
Given that this a solved problem and that the 2.36 release is over 3 years
old now, do you really need to know how/when the bug was actually fixed ?
Looking at the file Linker_Bug/Debug/Linker_bug.map (which I assume is for
the good build) it appears that the missing code is contained in the file:
C:/ST/STM32CubeIDE_1.14.1/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.10.3-2021.10.win32_1.1.200.202402032213/tools/bin/../lib/gcc/arm-none-eabi/10.3.1/thumb/v8-m.main+fp/hard/crtn.o
Which seems a little odd to me since the code that is present appears to come
from the crti.o file from the same directory. (I would not expect the code for
a single init function to be split across two object files). Unfortunately
without the files to examine, I cannot be sure.
There does not appear to be a linker map file for the bad build, and without
access to those system files I cannot run the build myself. But if you can,
then maybe the map file will show what has happened to the .init section from
the crtn.o object file.
You state that the difference between the good and bad links is that fact
that a different LMA/VMA relationship is used. But when I checked the scripts
in the zip file you provided this did not appear to be the case:
$ diff STM32H563AIIXQ_FLASH2RAM_BAD.ld STM32H563AIIXQ_FLASH2RAM_GOOD.ld
79a80,85
> . = ALIGN(4);
> __exidx_start = .;
> *(.ARM.exidx*)
> __exidx_end = .;
> . = ALIGN(4);
>
124,127d129
< __exidx_start = .;
< *(.ARM.exidx*)
< __exidx_end = .;
<
Have I missed something ?
Cheers
Nick
--
You are receiving this mail because:
You are on the CC list for the bug.
