Use LLVM LLD linker #993

bradjc · 2018-06-13T22:29:37Z

Pull Request Overview

This pull request changes the build system to use LLVM LLD rather than GNU LD as the linker.

In theory this is a very minor change. In practice, two things are different:

The MEMORY command in the linker file does not work with variables. Therefore, each platform will have to define its own memory section. I have done this for hail, and can apply it more broadly if everyone is cool with this PR.
Simply doing . = . + STACK_SIZE; is no longer a valid way to set up the .stack section so that it is the correct size. The resulting .elf has a .stack section which is the correct length, but the next section (.relocate) is placed on top of it (i.e. it is at the same address). I have found two workarounds for this, the first is to use 512 QUAD(0x00) statements in the linker file to fill the space. This kinda works, in that it makes the .stack section the correct size, but for some reason the resulting .bin file becomes 512MB so the kernel doesn't actually work. The other solution is the one in this PR: make a dummy array in rust and then assign it to the section.

The faulty .elf:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .text             PROGBITS        00010000 001000 015230 00 AXM  0   0 32
  [ 2] .ARM.exidx        ARM_EXIDX       00025230 016230 000010 00  AL  1   0  4
  [ 3] .storage          NOBITS          0002523f 016240 0001c1 00   A  0   0  1
  [ 4] .apps             NOBITS          00030000 017000 000000 00   A  0   0  1
  [ 5] .stack            NOBITS          20000000 017000 001000 00   A  0   0  1
  [ 6] .relocate         PROGBITS        20000000 017000 000e2c 00  WA  0   0  8
  [ 7] .sram             NOBITS          20000e30 017e2c 00f1d0 00  WA  0   0 16

The workaround is a little unfortunate, but maybe either I am missing something or LLD 7.0 will fix this.

Testing Strategy

This pull request was tested by running hail on hail.

TODO or Help Wanted

This pull request still needs to be updated for all other boards.

Also, I think this is worth it to get to fewer dependencies and better exist in the rust ecosystem, but others may have different thoughts.

Documentation Updated

Kernel: Updated the relevant files in /docs, or no updates are required.
Userland: Added/updated the application README, if needed.

Formatting

Ran make formatall.

ppannuto

A nice notion to lessen toolchains required, but I don't think LLD is ready for primetime yet :/

ppannuto · 2018-06-13T22:38:08Z

boards/kernel_layout.ld

@@ -226,7 +216,7 @@ SECTIONS

        . = ALIGN(4);
        _erelocate = .;
-    } > ram AT > rom
+    } > ram


This is a regression too, and a pretty serious one. This syntax ensures that this section is charged to both the ram and rom sections. The AT syntax simply places it there without accounting for size. This silent failure was the root cause of a pretty awful to track down signpost bug.

AT > rom doesn't seem to work with lld. Instead, I added an assert to the bottom of the linker script. Take a look and see if that would also catch the error.

Haven't tested, but shouldn't that be < LENGTH(rom) not > LENGTH(rom)?

It only compiles this way.

ppannuto · 2018-06-13T22:39:12Z

boards/hail/src/main.rs

+/// stack.
+#[no_mangle]
+#[link_section = ".stack_buffer"]
+pub static mut STACK_MEMORY: [u8; 0x1000] = [0; 0x1000];


I'm generally adverse to having the same information duplicated in two places. Is the STACK_SIZE variable in the linker script still used with this approach or could it possible be dropped?

ppannuto · 2018-06-13T22:40:43Z

boards/hail/chip_layout.ld

+{
+  rom (rx)  : ORIGIN = 0x00010000, LENGTH = 0x00020000
+  prog (rx) : ORIGIN = 0x00030000, LENGTH = 0x00040000
+  ccfg (rx) : ORIGIN = 0,          LENGTH = 0


I'm a little wary of the copy/paste that this introduces here. i.e. the ccfg section doesn't really make sense to be in the hail memory map at all? Granted it was there in the general case, but that's hidden away. Now that it's in the "hail-specific" file, it's odd to see it.

Yeah that can be removed from boards that do not use it.

If you remove the ccfg definition here, does this part of the linker file cause problems?

.ccfg : { KEEP(*(.ccfg)) } > ccfg

Or does it just silently ignore undefined, empty things?

Doesn't seem to mind.

ppannuto · 2018-06-14T19:13:46Z

boards/hail/chip_layout.ld

@@ -7,3 +8,11 @@ RAM_ORIGIN  = 0x20000000;
 RAM_LENGTH  = 0x00020000;

 MPU_MIN_ALIGN = 8K;
+
+MEMORY


I think if we do this we can kill off all the variables above too. Doesn't look like they're used anywhere else.

alevy · 2018-06-19T14:34:20Z

While I appreciate @ppannuto's concerns, I find it suspicious we wouldn't be able to link the kernel with LLD, given that the much more complicated libtock-rs userland is linked with LLD---it's just a fairly straight forward linking process that's only somewhat complicated due to our build system helping avoid duplication across boards.

My question is how to best stress test this. One option is to merge, see if/how it starts breaking for people before the next release, and fix or revert before then. Another option, would be to somehow test rigorously before merging. I'm personally more sympathetic to merging and fixing, since I suspect this is probably pretty close.

ppannuto · 2018-06-19T14:44:44Z

I would like to test this, especially the region size stuff. I’m out of country till Friday. I’d like to leave a block till Monday night, assuming I can look at it on Monday or I’ll get out of the way of progress if I don’t get to it by Monday night and fix anything later

…

On Tue, Jun 19, 2018 at 2:34 PM Amit Levy ***@***.***> wrote: While I appreciate @ppannuto <https://github.com/ppannuto>'s concerns, I find it suspicious we wouldn't be able to link the kernel with LLD, given that the much more complicated libtock-rs userland is linked with LLD---it's just a fairly straight forward linking process that's only somewhat complicated due to our build system helping avoid duplication across boards. My question is how to best stress test this. One option is to merge, see if/how it starts breaking for people before the next release, and fix or revert before then. Another option, would be to somehow test rigorously before merging. I'm personally more sympathetic to merging and fixing, since I *suspect* this is probably pretty close. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#993 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAUt3sf5nlSaD3a9ca8TCWsUzhiEdo22ks5t-QvygaJpZM4UnCTQ> .

This switches the build system to use the LLVM linker (lld) that ships with rust rather than arm-none-eabi-gcc.

Variables do not work the same as in gnu ld, so we have to include the `MEMORY` section directly in each board's linker file.

bradjc · 2018-06-19T20:12:56Z

Testing is good. I just updated so that all boards now use this.

Also I was totally wrong about the ASSERT; I wasn't taking into account that the kernel on hail starts at 0x10000.

Monday night has passd.

ppannuto previously requested changes Jun 13, 2018

View reviewed changes

ppannuto reviewed Jun 14, 2018

View reviewed changes

alevy added the P-Significant This is a substancial change that requires review from all core developers. label Jun 16, 2018

niklasad1 mentioned this pull request Jun 19, 2018

Tracking: Minimize dependencies to build kernel #866

Closed

5 tasks

bradjc added 3 commits June 19, 2018 16:09

boards: use llvm lld

b5d7f89

This switches the build system to use the LLVM linker (lld) that ships with rust rather than arm-none-eabi-gcc.

boards: update all boards to use new linker file

24bf4e1

Variables do not work the same as in gnu ld, so we have to include the `MEMORY` section directly in each board's linker file.

make: boards: do not need check for gcc anymore

be73fa7

bradjc force-pushed the llvm-lld branch from 8153fe7 to be73fa7 Compare June 19, 2018 20:11

bradjc assigned ppannuto Jun 21, 2018

alevy approved these changes Jun 26, 2018

View reviewed changes

bradjc merged commit 1a66eb0 into master Jun 26, 2018

bradjc deleted the llvm-lld branch June 26, 2018 12:31

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Use LLVM LLD linker #993

Use LLVM LLD linker #993

bradjc commented Jun 13, 2018 •

edited

Loading

ppannuto left a comment

ppannuto Jun 13, 2018

bradjc Jun 13, 2018

ppannuto Jun 14, 2018

bradjc Jun 14, 2018

ppannuto Jun 13, 2018

bradjc Jun 13, 2018

ppannuto Jun 13, 2018

bradjc Jun 13, 2018

ppannuto Jun 14, 2018

bradjc Jun 14, 2018

ppannuto Jun 14, 2018

bradjc Jun 14, 2018

alevy commented Jun 19, 2018

ppannuto commented Jun 19, 2018 via email

bradjc commented Jun 19, 2018

Use LLVM LLD linker #993

Use LLVM LLD linker #993

Conversation

bradjc commented Jun 13, 2018 • edited Loading

Pull Request Overview

Testing Strategy

TODO or Help Wanted

Documentation Updated

Formatting

ppannuto left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alevy commented Jun 19, 2018

ppannuto commented Jun 19, 2018 via email

bradjc commented Jun 19, 2018

bradjc commented Jun 13, 2018 •

edited

Loading