I spent a bunch of time conversing with Chris Johns on Discord about this issue
and Chris, with infinite patience, helped me find a possible issue.
Using rtems-exeinfo -O we noticed an issue
| __atexit.c: -mcpu=arm7tdmi -marm -march=armv4t
| __call_atexit.c
> On 2021-August-12, at 03:36, Sebastian Huber
> wrote:
>
> On 11/08/2021 18:22, Mr. Andrei Chichak wrote:
>> On 2021-August-11, at 01:06, Sebastian
>> Huber wrote:
>>> On 10/08/2021 23:48, Mr. Andrei Chichak wrote:
From what I can figure out, there seems to be a problem with the
On 11/08/2021 18:22, Mr. Andrei Chichak wrote:
On 2021-August-11, at 01:06, Sebastian
Huber wrote:
On 10/08/2021 23:48, Mr. Andrei Chichak wrote:
From what I can figure out, there seems to be a problem with the
out-of-the-box build of newly that the STM32F4 uses.
memset() goes for a few ARM
On 2021-August-11, at 01:06, Sebastian Huber
wrote:
>
> On 10/08/2021 23:48, Mr. Andrei Chichak wrote:
>> From what I can figure out, there seems to be a problem with the
>> out-of-the-box build of newly that the STM32F4 uses.
>> memset() goes for a few ARM instructions and then seems to intent
On 10/08/2021 23:48, Mr. Andrei Chichak wrote:
From what I can figure out, there seems to be a problem with the
out-of-the-box build of newly that the STM32F4 uses.
memset() goes for a few ARM instructions and then seems to intentionally
branch into, what the map file indicates is, the middle
Sorry, I put in newlib and this stupid mail program put in newly.
> On 2021-August-10, at 15:48, Mr. Andrei Chichak wrote:
>
> From what I can figure out, there seems to be a problem with the
> out-of-the-box build of newly that the STM32F4 uses.
>
> memset() goes for a few ARM instructions an
From what I can figure out, there seems to be a problem with the out-of-the-box
build of newly that the STM32F4 uses.
memset() goes for a few ARM instructions and then seems to intentionally branch
into, what the map file indicates is, the middle of fflush().
newly would have been built with th
