v0.4.0: with LLD support #64
Conversation
|
Dropping stack overflow protection is kind of unfortunate but given that it required the custom linking step maybe it's good that it's gone. I think that a proper solution can be much more easily developed for lld than binutils, especially given that rustc ships a fork of lld now. |
| } > RAM AT > FLASH | ||
| /* NOTE(AT > FLASH) without this LLD v6 produces a binary that crashes OpenOCD whereas LLD v7 | ||
| emits a ".rodata and .bss sections overlap" error ... This hacky workaround doesn't increase | ||
| the binary size AFAICT */ |
There was a problem hiding this comment.
One drawback is this will make firmwares with really full flashes uncompilable. Do I understand it right that lld v7 doesn't require the workaround?
There was a problem hiding this comment.
Do I understand it right that lld v7 doesn't require the workaround?
No, this also needed for the v7 I tested. Without the workaround linking with LLD fails with the error message in the comment; GNU LD can link the same program without errors and produces a binary that doesn't crash OpenOCD.
There was a problem hiding this comment.
Are you going to look at the underlying lld bug? I don't yet use lld for my embedded development so I'm afraid you're in the better position here. I can review though.
There was a problem hiding this comment.
I will at least submit a bug report. I have zero experience hacking LLVM :-).
There was a problem hiding this comment.
fwiw, with arm-none-eabi-ld at least, this doesn't cause problems even when bss is larger than the entire flash space, everything works as it should (surprisingly?). I haven't tried with lld.
|
I just tested this with my microbit crate. Works fine with both arm-none-eabi-binutils and lld. Flash image size is identical, disk size with debugging symbols went down a bit and surprisingly lld produces slightly larger files on disk than GNU ld but that's nothing to worry about. |
I think it's very unlikely that the Rust team will add features to rust fork of lld. They try to keep as few patches (that are not backports) as possible on top of upstream LLVM / LLD. I do agree that a LLD (linker script?) solution would be the ideal solution here. |
this commit adds LLD support by removing all INFO sections. LLD kind of supports INFO in the form of NOLOAD but when the linker script contains NOLOAD sections LLD emits a binary with false `size` information: for example, it reported a fake increase of 20KB in .text and a fake increase of 1KB in .bss when compiling a program that only allocates a single Box. As the INFO sections are gone we can no longer support the stack overflow protection added in #43 so all the other related changes, like making _stack_start overridable, have been removed as well. If you want to continue using stack overflow protection you can stick to v0.3.x. As the .debug_gdb_scripts output section has been removed from the linker script these changes will only reliably support both LD and LLD if/when rust-lang/rust#49728 lands. closes #53
Minor version has been bumped to v0.4.0 so we can stop supporting them This also drop the chrono dependency, which some people have been running into problems with. closes #60
mainly from the docs
it wasn't mean to be removed -- it's not related to the stack overflow protection stuff
they were leftover from rebasing closes #31
|
As we are making a new version release I'm also removing the panic_fmt lang item and the abort-on-panic feature. rust-lang/rust#47074 has been fixed and |
I mean that the features can be added upstream and then pulled to the rust fork of lld to avoid waiting for an LLVM release cycle, of course. |
|
Alright, let's land this to get more real world testing. |
See commit messages for details about why this is a breaking change.
I personally think no longer requiring GNU LD / arm-none-eabi-binutils to build a Rust program is worth the breaking change.
So far this seems to work fine but I'll continue to test this locally.
This depends on rust-lang/rust#49728