static vars not initialised

[blippy]

I don't think my static variables are being set. Suppose I have a simple function:

Code: Select all

void foo()
{
        static void*xxx = 0;
        assert(xxx==0);
}

I run it:

Code: Select all

assertion failed:kernel.c:71:foo():xxx==0

I'm baffled.

[cleverca22]

any variable that is set to 0 gets allocated into the .bss section by default
the linker will omit .bss from the actual binary, and the init code is then responsible for zeroing out bss on startup, before entering main()

you should then use the linker script to create 2 symbols at the start/end (objdump -t may show them already existing)
then you need to zero that area of ram out before main() gets ran, either in asm or in some pre-main c code

[blippy]

any variable that is set to 0 gets allocated into the .bss section by default
the linker will omit .bss from the actual binary, and the init code is then responsible for zeroing out bss on startup, before entering main()

you should then use the linker script to create 2 symbols at the start/end (objdump -t may show them already existing)
then you need to zero that area of ram out before main() gets ran, either in asm or in some pre-main c code

Thanks. I tried that, and it seemed to solve the problem. You don't know how much time I wasted trying to get that sorted!

[jahboater]

This compiler option may be of interest:

Code: Select all

-fno-zero-initialized-in-bss
   If the target supports a BSS section, GCC by default puts variables that are
   initialized to zero into BSS.  This can save space in the resulting code.
 
   This option turns off this behavior because some programs explicitly rely on variables
   going to the data section---e.g., so that the resulting executable can find the
   beginning of that section and/or make assumptions based on that.
 
   The default is -fzero-initialized-in-bss.

[cleverca22]

This compiler option may be of interest:

Code: Select all

-fno-zero-initialized-in-bss
   If the target supports a BSS section, GCC by default puts variables that are
   initialized to zero into BSS.  This can save space in the resulting code.
 
   This option turns off this behavior because some programs explicitly rely on variables
   going to the data section---e.g., so that the resulting executable can find the
   beginning of that section and/or make assumptions based on that.
 
   The default is -fzero-initialized-in-bss.

but that only covers vars that you explicitely set to 0
if you didnt set it, then it would still wind up in .bss, and the same issue would occur

[sean.lawless]

any variable that is set to 0 gets allocated into the .bss section by default
the linker will omit .bss from the actual binary, and the init code is then responsible for zeroing out bss on startup, before entering main()

you should then use the linker script to create 2 symbols at the start/end (objdump -t may show them already existing)
then you need to zero that area of ram out before main() gets ran, either in asm or in some pre-main c code

Thanks. I tried that, and it seemed to solve the problem. You don't know how much time I wasted trying to get that sorted!

Apologies blippy, I believe the zeroing of .bss is missing from the lab's in my book. If you share I can add it.

[blippy]

Apologies blippy,

No problemo. I didn't intend it to be a complaint. Sometimes sorting out these bugs can be very confusing.

I believe the zeroing of .bss is missing from the lab's in my book. If you share I can add it.

Sure. My solution is pretty much a standard one.

In memory.map, you need to change

Code: Select all

    .bss : { *(.bss*) } > ram

to

Code: Select all

	.bss : { 
		_sbss = .;
		__bss_start__ = _sbss;
		*(.bss*);
		*(.bss*);
		*(COMMON);
		. = ALIGN(4);
		_ebss = .;
		__bss_end__ = _ebss;
	} > ram

A bit messier, and maybe all of it isn't strictly necessary. Now, __bss_start__ and __bss_end__ will be exported symbols, marking the beginning and end of the BSS section. We can use those symbols to zero out our code.

There's a few ways you can do the zeroing out. Some do it in assembler, but I think that's best avoided. Write it in C. You still need to tweak app.s a little, though. Change:

Code: Select all

  bl main

to:

Code: Select all

  bl pre_main
  bl main

pre_main will, of course, do the zeroing. Here's the implementation, which you can put in some common C file:

Code: Select all

extern uintptr_t __bss_start__[];
extern uintptr_t __bss_end__[];

/* Zero the BSS section 4-bytes at a time */
void pre_main(void)
{
    uint32_t *memloc = (uint32_t*)__bss_start__;

    while (memloc < (uint32_t*)__bss_end__)
        *memloc++ = 0;
}

Hope that helps.

Many thanks for your tutorials and books, BTW. Trying to implement something cold just by reading the datasheets isn't feasible for me. It's much better to crib from folks who have figured it all out before.

[LdB]

Fixed non zero constant data goes into the .rodata segment on most C compilers including GCC ... you can work around it in GCC with -fno-common but really the linker file should have an .rodata section just in case it gets used.

[jahboater]

Code: Select all

extern uintptr_t __bss_start__[];
extern uintptr_t __bss_end__[];

/* Zero the BSS section 4-bytes at a time */
void pre_main(void)
{
    uint32_t *memloc = (uint32_t*)__bss_start__;

    while (memloc < (uint32_t*)__bss_end__)
        *memloc++ = 0;
}

If the BSS section is a multiple of 32-bytes or more, perhaps something like this could be used?

Code: Select all

static inline void
clear( void *dst, size_t len )
{
  asm("dup v0.2d,xzr; 1: sub %1,%1,32; stp q0,q0,[%0],32; cbnz %1,1b"
      : "+r" (dst), "+r" (len) :: "q0", "memory");
}

STP Q0,Q0,[%0],32 writes 32 bytes of zeros and updates the pointer.
Its the fastest way of zeroing memory on the Pi that I have found.

For 16 byte multiples STP XZR,XZR,[%0],16 is quick too.

[cleverca22]

beware, the stack might be in the .bss (depending on the linker script)
it may help to clear the .bss using hand-rolled asm, that will never touch the stack

here are some more examples, ive how its done in projects i manage

Code: Select all

	.bss : {
		_edata = .;
		__bss_start = .;
                *(.bss.page_table)
		*(.bss)
		*(.bss.*)
                __bss_end = .;
	}

.bss.page_table is just a special custom thing, that i wanted at the start of the bss, i forget why

Code: Select all

  if (corenr == 0) {
    bzero(&__bss_start, &__bss_end - &__bss_start);
    udelay(30000); // the first few prints get cut off if this delay is lower
    heap_init();
    printf("r0 is %lx\n", r0);
    init_page_tables(ramSizeInMb());
    main();
  }

this chunk of the code gets ran on all 4 arm cores at once, but only one should zero things out and then run main()
all of the arm code is under https://github.com/librerpi/rpi-open-fi ... hainloader if you want to see it in context

and then a non-arm example

Code: Select all

  .bss : {
    __bss_start = .;
    *(.bss)
    *(COMMON)
    . = ALIGN(32 / 8);
    _end = . ;
  }
  /* First location in stack is highest address in RAM */
  _fstack = ORIGIN(ram) + LENGTH(ram) - 4;

and i notice here, the stack begins at the top of ram, and grows downward, towards the bss
and on some configurations, the heap begins at _end, and grows upwards
things crash when heap and stack collide, so you have to keep usage low, and balance the 2
in this case, stack isnt inside bss, so no problems like i said at the start

and this version lacks the code to clear the .bss, because the bootloader before it has already done so, but i can now see how that could be a bit buggy, what with global vars left behind by the previous stage, landing in just the wrong addr

[sean.lawless]

Thanks @blippy and @cleverca22. I reviewed my notes on this and it is clear the omission of clearing bss was intentional in the book and labs. It is potentially very confusing as cleverca22 pointed out. Instead of clearing static globals in .bss, all static and global variables were instead initialized in the startup code. This said, it is customary that C applications execute with a clear bss and I will add an example that does this to Lab24. If you add code that relies on clearing the bss, it will typically no longer be reentrant (unless you clear .bss again).

[piguy70]

The .bss segment is a compiler and linker construct.
Initialisation of the .bss segment is very common I have written this initialisation for a number of ARM's CPU's / core's and other architectures. Initialisation is often done in assembly I have written both ways 'C' and assembler.
Looking at the assembly produced from the C code this is just a efficient unless alignment is greater than 4, then the assembly can use multiple instruction read and write to speed this along.
On multi core systems the .bss segment is often initialised on the first core to start running and all other cores start after initialisation of the first core completes.

This segment is usually defined in a linker script, something like:

Code: Select all

__bss_start = .;
.bss : 
{ 
    . = ALIGN( 2 );
    *(.bss*) 
    *(COMMON*) 
    . = ALIGN( 2 );
}
__bss_end__ = . ;

Note the alignment is set to 4 bytes (or 1 << 2). This means that we could use assembly on a 32-bit arm or use C code
above it will work fine.

Then some simple assembly code would look like:

Code: Select all

.global __bss_start     // -> .bss area in RAM
.global __bss_end__     // end of .bss area

/* Clear .bss
 * ----------
 */
    mov   r0,#0                     /* get a zero */
    ldr   r1,=__bss_start           /* -> bss start */
    ldr   r2,=__bss_end__           /* -> bss end */
2:  cmp   r1,r2                     /* check if data to clear */
    strlo r0,[r1],#4                /* clear 4 bytes */
    blo   2b                        /* loop until done */

[LdB]

.ALIGN in a linker script is in bytes ... feel free to check and confirm
Your alignment above is 2 BYTES aka 16bit and unsuitable for an ARM32

I think you are confusing it with .ALIGN in assembler which also has .BALIGN

[cleverca22]

.ALIGN in a linker script is in bytes ... feel free to check and confirm
Your alignment above is 2 BYTES aka 16bit and unsuitable for an ARM32

I think you are confusing it with .ALIGN in assembler which also has .BALIGN

ive seen a number of somewhat fishy accounts that seem to necro a post and repeat most of the information that was already stated, this one fits the battern, but its often borderline so i dont bother the moderators

[sean.lawless]

I will add an example that does this to Lab24.

Lab24 'game' application updated to clear BSS. bzero() uses memset() so optimizations (32 bit aligned) can go into memset() in the future.

[afonteles]

I posted a question on another board that I believe might be related. If I have the following variables declared outside of a function:

Code: Select all

static int var = 1;
int *p_var = &(var);

It turns out later on that *p_var != var, without ever touching these variables before testing their values.

My bss is being initialized to zero, before I jump into my main function (for what is worth it).

After days trying to figure out what was happening I just gave up and used a work around with an init function that I called right after I jump into main:

Code: Select all

static int var;
int *p_var;

void init(void) {
    p_var = &(var);
}

Code: Select all

void kernel_main(void)
{
	init();
        ...
 }
 

That said, I'm just a poor Java developer, so I might be missing something

[blippy]

I posted a question on another board that I believe might be related. If I have the following variables declared outside of a function:

Code: Select all

static int var = 1;
int *p_var = &(var);

It turns out later on that *p_var != var, without ever touching these variables before testing their values.

Yes, it's a similar deal. This time, instead of zeroing out the memory, you must transfer it. I see that I haven't actually implemented a solution for the Pi, but I do have something for the STM32, which will hopefully help. It might not work exactly, but it should be a significant clue for you.

The idea is to have a "pre-main" function which is called before "main". Here's how it might look:

Code: Select all

void init_mem()
{
	// not called explicitly, but done in crt.s prior to calling main()

	// Copy initialized data from .sidata (Flash) to .data (RAM)
	memcpy( &_sdata, &_sidata, ( ( void* )&_edata - ( void* )&_sdata ) );
	// Clear the .bss section in RAM.
	memset( &_sbss, 0x00, ( ( void* )&_ebss - ( void* )&_sbss ) );
}

We're doing two things here: copying over data that should be initialised on boot, and zeroing out memory that needs to be zeroed. Your linker script should then look something like this:

Code: Select all

SECTIONS
{
...
/* The 'data' section is space set aside in RAM for
   * things like variables, which can change. */
  _sidata = .;
  .data : AT(_sidata)
  {
    . = ALIGN(4);
    /* Mark start/end locations for the 'data' section. */
    _sdata = .;
    *(.data)
    *(.data*)
    _edata = .;
    . = ALIGN(4);
  } >RAM

  /* The 'bss' section is similar to the 'data' section,
   * but its space is initialized to all 0s at the
   * start of the program. */
  .bss :
  {
    . = ALIGN(4);
    /* Also mark the start/end of the BSS section. */
    _sbss = .;
    __bss_start__ = _sbss;
    *(.bss)
    *(.bss*)
    *(COMMON)
    . = ALIGN(4);
    _ebss = .;
    __bss_end__ = _ebss;
  } >RAM
  
  ...

The complete linker file is available https://github.com/blippy/rpi/blob/mast ... /linker.ld. You may need to adapt it a little.

Somewhere in your startup asm file you'll have:

Code: Select all

    bl main

Change it to

Code: Select all

   bl init_mem
   bl main

So when you run main(), the init_mem() function will have already been called for you. You could also stuff whatever common initialisation code you want into it. I prefer not to do that, though, so as to maintain flexibility.

Using C++ classes would involve an additional ball of wax to get their initialisation working properly. I'm not sure how to do that yet, though.

Hope that helps.

[blippy]

OK, I've done a little investigation. Most of what I wrote in my previous post probably isn't necessary. I wrote the following code:

Code: Select all

#include <mini_uart.h>
#include <stdio.h>

static int var = 42;
int *p_var = &(var);

void kernel_main(void)
{
        uart_init_as_stdio(115200);
        puts("init test");
        printf("var=%d\n", *p_var);

        puts("I will now echo what you type");
        while (1) {
                char c = getchar();
                putchar(c);
        }
}

and it seems to work fine for me.

Source file: https://github.com/blippy/rpi/blob/mast ... t/kernel.c

Here's my linker script: https://github.com/blippy/rpi/blob/mast ... /linker.ld

Code: Select all

* bss sections mentioned here:
 * https://stackoverflow.com/q/43922511/4037492
 */

SECTIONS
{ 
        .text.boot 0x8000 : { *(.text.boot) }
        .text : { *(.text) }
        .rodata : { *(.rodata) }
        .data : { *(.data) }
        . = ALIGN(0x8);
	
	.bss : { 
		_sbss = .;
		__bss_start__ = _sbss;
		*(.bss*);
		*(.bss*);
		*(COMMON);
		. = ALIGN(4);
		_ebss = .;
		__bss_end__ = _ebss;
	} 


	.crunky_heap : {
		. = ALIGN(4);
		_sheap = .;
		__heap_start__ =  _sheap;
		. = . + 100000000; /* 100MB heap */
		. = ALIGN(4);
		_eheap = .;
		__heap_end__ = _eheap;
	}
}

For your purposes you may want to omit the "crunky_heap" section. I implement a heap with malloc goodies. My ASM file https://github.com/blippy/rpi/blob/mast ... /vectors.S is:

Code: Select all

;@-------------------------------------------------------------------------
;@-------------------------------------------------------------------------

//#include <basal.h>

#if RPI == 0
#warning "vectors reports RPI is 0"
#endif

.section .text.boot
.globl _start
_start:
    ldr pc,reset_handler
    ldr pc,undefined_handler
    ldr pc,swi_handler
    ldr pc,prefetch_handler
    ldr pc,data_handler
    ldr pc,unused_handler
    ldr pc,irq_handler
    ldr pc,fiq_handler
reset_handler:      .word reset
undefined_handler:  .word hang
swi_handler:        .word hang
prefetch_handler:   .word hang
data_handler:       .word hang
unused_handler:     .word hang
irq_handler:        .word IRQ_handler
fiq_handler:        .word hang

reset:
	
#if RPI != 0
    mrs r0,cpsr        				;@ moving to HYPERVISOR mode
    bic r0,r0,#0x1F
    orr r0,r0,#0x13
    msr spsr_cxsf,r0
    add r0,pc,#4
    msr ELR_hyp,r0
    eret
#endif

    mov r0,#0x8000
    mov r1,#0x0000
    ldmia r0!,{r2,r3,r4,r5,r6,r7,r8,r9}
    stmia r1!,{r2,r3,r4,r5,r6,r7,r8,r9}
    ldmia r0!,{r2,r3,r4,r5,r6,r7,r8,r9}
    stmia r1!,{r2,r3,r4,r5,r6,r7,r8,r9}

    ;@ (PSR_IRQ_MODE|PSR_FIQ_DIS|PSR_IRQ_DIS)
    mov r0,#0xD2
    msr cpsr_c,r0
    mov sp,#0x8000

    ;@ (PSR_FIQ_MODE|PSR_FIQ_DIS|PSR_IRQ_DIS)
    mov r0,#0xD1
    msr cpsr_c,r0
    mov sp,#0x4000

;@ 	The following are used to set the stack for alternative operating modes.
;@  In the present case, they are commented, thus ignored.
	
    ;@ (PSR_SVC_MODE|PSR_FIQ_DIS|PSR_IRQ_DIS)		
    ;@ mov r0,#0xD3
    ;@ msr cpsr_c,r0
    ;@ mov sp,#0x8000000

    ;@ SVC MODE, IRQ ENABLED, FIQ DIS
    ;@mov r0,#0x53
    ;@msr cpsr_c, r0
    
    bl zero_bss
    bl kernel_main
hang: b hang

.globl put32
put32:
    str r1,[r0]
    bx lr

.globl get32
get32:
    ldr r0,[r0]
    bx lr

.globl enable_irq
enable_irq:
    mrs r0,cpsr
    bic r0,r0,#0x80
    msr cpsr_c,r0
    bx lr

;@ From Bruce Smith's ARM32 ASM book page 283
.globl disable_irq
disable_irq:
    mrs r0,cpsr
    orr r0,r0,#0x80
    msr cpsr_c,r0
    bx lr

You'll basically want that file anyway, as it does nice froody things like set up interrupts.

I'm slowly building up my own "unikernel", which I'm calling "crunky". To test the example, you may want to clone my repo can check out the directory rpi/crunky.

I wouldn't say it's complete, or neat, but it has a lot of goodies in it, like malloc, a port of the bcm2835 lib (so you can do SPI, I2C), partial integration with nano_libc (so you nearly have a standard C library implementation). Even SD card support is in there.

It takes a "unikernel" approach, so there's no scheduler, and no pre-emption. There is an "async" library for if you want to do co-operative multitasking.

So, lots of things for people to play with. i haven't announced it yet, because it is still in a fairly rough stage.

The big thing that's missing is USB. That will be a really tough nut to crack. I'm aware that there are USB implementations out there, but none have satisfied me so far.

[afonteles]

blippy, thank you so much for your careful reply! I really appreciate it.

Unfortunately, I couldn't test your code directly because I have a PI 4. So, I tried to adapt it. It doesn't seem to work for me. In fact, the problem I'm having comes from following a PI 3 tutorial slightly adapted to PI 4 by me. I'm starting to suspect that there might be some difference between the PI 4 and 3 on this matter. No one seems to report any problem on this tutorial for PI 3 (https://github.com/s-matyukevich/raspberry-pi-os).

I'll investigate further on your code for the STM32 and see if something applies. At this moment I would think that copying the .data from flash is not necessary since the PI's GPU already seems to copy the whole content of the kernel.img to RAM.

I'll let you guys know if I find something out.

[dwelch67]

SECTIONS
{
.text : { *(.text*) } > ram
.rodata : { *(.rodata*) } > ram
.bss : { *(.bss*) } > ram
.data : { *(.data*) } > ram
}

note that if you have .data after .bss in the linker script and simply add a single .data item then both .data and .bss will be initialized in the kernel.img file. no extra code needed.

[afonteles]

So, after trying to put the .data right after the .bss, here are the values I get:

&var: 0000000000080858 <---- This address varies slightly each time
var: 0000000000000000 <---- This should be 1, not 0
p_var: 0000000000000858 <---- This is off by 0x80000....
*p_var: 0000000037326D63 <---- Just some rubish

The pointer is off by 0x80000. If I don't zero the bss, then I get the right value for var: 1. So, I'm assuming that if I put the data after the var I don't need zero the .bss..

Here is what my linker looks like

Code: Select all

	SECTIONS
	{
		.text.boot : { *(.text.boot) }
		.text : { *(.text) }
		.rodata : { *(.rodata) }
		. = ALIGN(0x8);
		bss_begin = .;
		.bss : { *(.bss*) }
		bss_end = .;
		.data : { *(.data*) }
	}

If I keep my .data before the .bss (and zero the bss), I have very similar values and var has the value of 1.

&var: 00000000000808A8
var: 0000000000000001 <---- This is correct now
p_var: 00000000000008A8 <---- Same thing, off by 0x80000....
*p_var: 000000005F637620 <---- Rubish data in the wrong address

[cleverca22]

are you using physical or virtual addresses?
is the kernel loading to the address you told the linker script it should be loaded at?

if the linker script doesnt agree with where you loaded the binary, then all of the addressing will be offset by some constant

[afonteles]

I love you all!!! S2 <3

I had to configure my kernel to load at the right memory address.

Code: Select all

	SECTIONS
	{
		. = 0x80000;	/* Kernel load address for AArch64 - that did the trick! */
		.text.boot : { *(.text.boot) }
		.text : { *(.text) }
		.rodata : { *(.rodata) }
		.data : { *(.data) }
		. = ALIGN(0x8);
		bss_begin = .;
		.bss : { *(.bss*) }
		bss_end = .;
	}

[cleverca22]

just make sure you load the right address into the VBAR register, and it should be fine

[afonteles]

Got it, thanks!