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

[BUG] RTCB can't be null since g_readytorun is in bss section #15020

Open
1 task done
PetervdPerk-NXP opened this issue Dec 2, 2024 · 5 comments
Open
1 task done

[BUG] RTCB can't be null since g_readytorun is in bss section #15020

PetervdPerk-NXP opened this issue Dec 2, 2024 · 5 comments
Assignees
Labels
Arch: arm Issues related to ARM (32-bit) architecture Area: OS Components OS Components issues OS: Linux Issues related to Linux (building system, etc) Type: Bug Something isn't working

Comments

@PetervdPerk-NXP
Copy link
Contributor

Description / Steps to reproduce the issue

https://github.com/apache/nuttx/blob/master/sched/sched/sched_lock.c#L80-L85
Mentions that rtcb may be NULL only during early boot-up phases however RTCB ends up in bss.

20002450 g     O .bss   00000008 g_readytorun

Therefore rtcb is a random value instead of NULL.

Not sure what would be better remove the sched_lock check or initialize g_readytorun as 0.

On which OS does this issue occur?

[OS: Linux]

What is the version of your OS?

Ubuntu

NuttX Version

Master

Issue Architecture

[Arch: arm]

Issue Area

[Area: OS Components]

Verification

  • I have verified before submitting the report.
@PetervdPerk-NXP PetervdPerk-NXP added the Type: Bug Something isn't working label Dec 2, 2024
@github-actions github-actions bot added Arch: arm Issues related to ARM (32-bit) architecture Area: OS Components OS Components issues OS: Linux Issues related to Linux (building system, etc) labels Dec 2, 2024
@acassis acassis assigned acassis and anchao and unassigned acassis Dec 3, 2024
@acassis
Copy link
Contributor

acassis commented Dec 3, 2024

@hujun260 @anchao please take a look!

@acassis
Copy link
Contributor

acassis commented Dec 3, 2024

@PetervdPerk-NXP .bss area is suppose to be zeroed early in the boot process, so it will not be a random value as you said.

@acassis
Copy link
Contributor

acassis commented Dec 3, 2024

This is from stm32_start.c:

  stm32_clockconfig();
  arm_fpuconfig();
  stm32_lowsetup();
  stm32_gpioinit();
  showprogress('A');

  /* Clear .bss.  We'll do this inline (vs. calling memset) just to be
   * certain that there are no issues with the state of global variables.
   */

  for (dest = (uint32_t *)_START_BSS; dest < (uint32_t *)_END_BSS; )
    {
      *dest++ = 0;
    }

  showprogress('B');

@anchao
Copy link
Contributor

anchao commented Dec 4, 2024

It looks similar to the problem @PeterBee97 solved before #14889 .
Before BSS is initialized, the boot-up code should avoid using any kernel API.

This is a common problem, we need to adjust the startup code to ensure BSS initialization earlier. @GUIDINGLI @hujun260 could you arrange resources to invest in this? I am not working on nuttx projects recently. CC @xiaoxiang781216

@xiaoxiang781216
Copy link
Contributor

The problem is clear that .bss need to be initialized before os, even before any c code, except the code which zero memory.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Arch: arm Issues related to ARM (32-bit) architecture Area: OS Components OS Components issues OS: Linux Issues related to Linux (building system, etc) Type: Bug Something isn't working
Projects
None yet
Development

No branches or pull requests

5 participants