Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pseudo-random behavior of GCC start-up template when main() returns #15

Open
0xa000 opened this issue Sep 13, 2024 · 3 comments
Open

Pseudo-random behavior of GCC start-up template when main() returns #15

0xa000 opened this issue Sep 13, 2024 · 3 comments
Assignees
Labels
bug Something isn't working cmsis CMSIS-related issue or pull-request. good first issue Good for newcomers internal bug tracker Issue confirmed and reported into a ticket in the internal bug tracking system.
Milestone

Comments

@0xa000
Copy link

0xa000 commented Sep 13, 2024

Board: NUCLEO-H723ZG
Compiler: arm-none-eabi-gcc (Arch Repository) 14.1.0

The GCC start-up assembly template for the H723xx (see here) contains the following code at the end of Reset_Handler:

/* Call static constructors */
  bl __libc_init_array
/* Call the application's entry point.*/
  bl  main
  bx  lr

Usually, main is assumed not to return. However, if it does, the next instruction BX LR will jump to the address stored in the link register. This address will usually be the return address for the last sub-routine call inside main. So, this instruction will jump back into main to a more or less random location. In my particular case, this location was close to the end of main, and execution continued through to the end of main where it pop-ed a value of zero into the program counter. This then triggered a hard fault, because zero is not a thumb mode address, and the default hard fault handler (an infinite loop) was entered.

Of course, one can debate about the desired behavior if main returns, but I think we can agree the current behavior is not it. One approach would be to replace BX LR with an infinite loop, similar to the GCC start-up templates for the H5 series. See for example this snippet below (taken from here):

/* Call static constructors */
  bl __libc_init_array
/* Call the application's entry point.*/
  bl main

LoopForever:
    b LoopForever

One could also consider throwing in a call to __libc_fini_array() after main and before the infinite loop for symmetry.

@sidneycadot
Copy link

sidneycadot commented Sep 13, 2024

I had a cursory look at some different stm32 mcu's startup code assembly, it appears that this is done this way across the startup code of more STM32 families; the nonsensical "bx lr" and the missing __libc_fini_array() call is also in the F4 startup code. The H5 startup code has an infinite loop after return from main() -- but no call to _libc_fini_array().

It would be best to homogenize this across all families, I think. That would take a sweep across a bunch of repositories.

In general, the behavior when returning from main() should be documented. If the choice is made to not touch the current implementation (for fear of breaking stuff, for example), I'd like to see a clear statement somewhere in the documentation that returning from main() triggers undefined behavior. I wouldn't favor that approach, but it's better than having UB and not documenting it.

@ALABSTM ALABSTM added bug Something isn't working cmsis CMSIS-related issue or pull-request. good first issue Good for newcomers labels Sep 13, 2024
@TOUNSTM
Copy link
Contributor

TOUNSTM commented Sep 18, 2024

Hello @0xa000,

Your point seems very relevant. It has been forwarded to our development teams. I will keep you informed.

With regards,

@TOUNSTM TOUNSTM moved this from To do to Analyzed in stm32cube-mcu-cmsis-dashboard Sep 18, 2024
@TOUNSTM
Copy link
Contributor

TOUNSTM commented Sep 27, 2024

ST Internal Reference: 192331

@TOUNSTM TOUNSTM moved this from Analyzed to In progress in stm32cube-mcu-cmsis-dashboard Sep 27, 2024
@TOUNSTM TOUNSTM added the internal bug tracker Issue confirmed and reported into a ticket in the internal bug tracking system. label Sep 27, 2024
@ALABSTM ALABSTM moved this from In progress to To release in stm32cube-mcu-cmsis-dashboard Oct 31, 2024
@ALABSTM ALABSTM moved this from To release to In progress in stm32cube-mcu-cmsis-dashboard Oct 31, 2024
@ALABSTM ALABSTM added this to the v1.10.6 milestone Oct 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working cmsis CMSIS-related issue or pull-request. good first issue Good for newcomers internal bug tracker Issue confirmed and reported into a ticket in the internal bug tracking system.
Projects
Development

No branches or pull requests

4 participants