Sure, no problem!
I'm currently not at home but I will run the tests on the hardware in the evening today or tomorrow morning (UTC +1).

I ran now a couple of test programs (blink, button, helloworld, ipc, etc.) , and everything seems to work fine. However, I stumbled across a different problem which might be a bug in the linking-stage or within the kernel-linker-script.

When I run make flash everything works fine, and the binary fits into the reserved flash-space.
Running make flash-debug creates a binary which is slightly too big for the reserved flash. And then I realized that that the .bss section is copied into the actual hex-file. I get the following output:

   text    data     bss     dec     hex 
  81921       0   16384   98305   18001

Initially I thought maybe .bss and .data are interchanged, but when I make the following changes to main.rs:

pub static mut TEST: usize = 334;

unsafe fn startup_intilialisation() {
    msp432::init();

    TEST += 1;
    ...
}

I get the following output:

   text    data     bss     dec     hex 
 114689       4   16128  130821   1ff05

So obviously .bss and .data are not interchanged.
And as far as I know the .bss contains only uninitialized data which gets zeroed after startup. Should this really be in the binary?
And if this is a bug, should I open an issue?

If by "end up in the binary" you mean "ends up in flash" I don't think that is happening. The GNU-size utility used to print the size information says the following:

The Berkeley style output counts read only data in the text column, not in the data column, the dec and hex columns both display the sum of the text, data, and bss columns in decimal and hexadecimal respectively.

So I think we are seeing exactly what we should expect.

If by "end up in the binary" you mean "ends up in flash" I don't think that is happening. The GNU-size utility used to print the size information says the following:

The Berkeley style output counts read only data in the text column, not in the data column, the dec and hex columns both display the sum of the text, data, and bss columns in decimal and hexadecimal respectively.

So I think we are seeing exactly what we should expect.

Ok, thanks for the answer!

I am still a bit confused about this because when flashing the binary with openocd it always prints the amount of flashed bytes. And this number equals exactly the decimal or hexadecimal column. But it's not a big problem, I'll try to find the problem when I have time (:

bors d+

✌️ hudson-ayers can now approve this pull request. To approve and merge a pull request, simply reply with bors r+. More detailed instructions are available here.

bors r+

rebased to resolve conflicts

Will this PR be merged in the near future? Because I have some fixes pending for this platform but I thought it doesn't make sense to open a PR before this one isn't merged.

Timed out.

bors retry

Timed out.

bors r+

Build succeeded:

• ci-format (ubuntu-latest)
• ci-format (macos-latest)
• ci-tests (macos-latest)
• ci-build (ubuntu-latest)
• ci-tests (ubuntu-latest)
• ci-qemu
• ci-build (macos-latest)