Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
|
|
now that 1.31 is out
|
|
|
|
|
|
so it matches the exception name (`#[exception] fn HardFault(..`)
|
|
|
|
to point to the "Reexports" section. The older links don't work correctly on
docs.rs. The "Reexports" section always has valid links to the documentation of
each attribute.
|
|
the service is now being maintained by the rust org
|
|
|
|
after #140 landed the entry, exception and interrupt attributes started
accepting code like this:
``` rust
#[entry]
fn main() -> ! {
static mut FOO: u32 = 0;
static mut FOO: i32 = 0;
}
```
because that code expands into:
``` rust
fn main() -> ! {
let FOO: &'static mut u32 = unsafe {
static mut FOO: u32 = 0;
&mut FOO
};
// shadows previous variable
let FOO: &'static mut u32 = unsafe {
static mut FOO: i32 = 0;
&mut FOO
};
}
```
this commit adds a check that rejects `static mut`s with duplicated names to
these three attributes.
|
|
Fixes #137
|
|
143: `b UserHardFault` r=adamgreig a=japaric
this commit replaces the `bl UserHardFault` instruction in HardFault with `b
UserHardFault`. This lets us drop the prologue (`push {r0,lr}`) while preserving
the ability to unwind the stack using GDB.
To prevent linker errors about relocations when UserHardFault and HardFault end
up far away from each other and the target is ARMv6-M (where the `b` instruction
only supports offsets of +/- 2KB) we use two *input* sections: .HardFault and
.UserHardFault. HardFault is placed in the .HardFault section and UserHardFault
is placed in the .UserHardFault section. The .HardFault input section is placed
in the output .text section after all the input .text sections, and the
.UserHardFault input section is placed after the .HardFault section. This
causes the two symbols to always appear next to each other in the output binary,
furthermore UserHardFault *always* appears after HardFault so the branch offset
of `b UserHardFault` is always a few bytes.
It should be noted that neither .HardFault or .UserHardFault will appear in the
output of the `size -A` command as they are input sections that get merged into
the output .text section. IOW, the sizes of HardFault and UserHardFault will
continue to be reported under the .text section.
cc @adamgreen
Co-authored-by: Jorge Aparicio <jorge@japaric.io>
|
|
this commit replaces the `bl UserHardFault` instruction in HardFault with `b
UserHardFault`. This lets us drop the prologue (`push {r0,lr}`) while preserving
the ability to unwind the stack using GDB.
To prevent linker errors about relocations when UserHardFault and HardFault end
up far away from each other and the target is ARMv6-M (where the `b` instruction
only supports offsets of +/- 2KB) we use two *input* sections: .HardFault and
.UserHardFault. HardFault is placed in the .HardFault section and UserHardFault
is placed in the .UserHardFault section. The .HardFault input section is placed
in the output .text section after all the input .text sections, and the
.UserHardFault input section is placed after the .HardFault section. This
causes the two symbols to always appear next to each other in the output binary,
furthermore UserHardFault *always* appears after HardFault so the branch offset
of `b UserHardFault` is always a few bytes.
It should be noted that neither .HardFault or .UserHardFault will appear in the
output of the `size -A` command as they are input sections that get merged into
the output .text section. IOW, the sizes of HardFault and UserHardFault will
continue to be reported under the .text section.
|
|
142: attributes: turn panics into compile errors r=therealprof a=japaric
Sample error messages:
```
error: `#[entry]` function must have signature `[unsafe] fn() -> !`
--> examples/error.rs:15:1
|
15 | fn main() {
| ^^
error: aborting due to previous error
```
```
error: This attribute accepts no arguments
--> examples/error.rs:14:1
|
14 | #[entry(hello)]
| ^^^^^^^^^^^^^^^
error: aborting due to previous error
```
```
error: This is not a valid exception name
--> examples/error.rs:20:4
|
20 | fn foo() {}
| ^^^
error: aborting due to previous error
```
Co-authored-by: Jorge Aparicio <jorge@japaric.io>
|
|
|
|
Sample error messages:
```
error: `#[entry]` function must have signature `[unsafe] fn() -> !`
--> examples/error.rs:15:1
|
15 | fn main() {
| ^^
error: aborting due to previous error
```
```
error: This attribute accepts no arguments
--> examples/error.rs:14:1
|
14 | #[entry(hello)]
| ^^^^^^^^^^^^^^^
error: aborting due to previous error
```
```
error: This is not a valid exception name
--> examples/error.rs:20:4
|
20 | fn foo() {}
| ^^^
error: aborting due to previous error
```
|
|
141: entry/exception/interrupt: reachability restriction is 1.30-only r=therealprof a=japaric
Thanks to rust-lang/rust#54451, which will be available in 1.31, these
attributes will work regardless of the visibility and reachability of the items.
Co-authored-by: Jorge Aparicio <jorge@japaric.io>
|
|
Thanks to rust-lang/rust#54451, which will be available in 1.31, these
attributes will work regardless of the visibility and reachability of the items.
|
|
this is required to implement safe interfaces to things like writable
Flash (e.g. EEPROM emulation) which require the `#[link_section]` attribute.
|
|
this changes code generation of code like this:
``` rust
#[entry]
fn main() -> ! {
static mut FOO: u32 = 0;
// ..
}
```
from this:
``` rust
fn main() -> ! {
static mut FOO_: u32 = 0;
let FOO: &'static mut u32 = unsafe { &mut FOO_ };
// ..
}
```
to this:
``` rust
fn main() -> ! {
let FOO: &'static mut u32 = unsafe {
static mut FOO: u32 = 0;
&mut FOO;
};
// ..
}
```
this completely hides the `static mut` variable. Before it was possible to
(unsafely) access it via `${ident}_` (e.g. `FOO_`).
|
|
Signed-off-by: Daniel Egger <daniel@eggers-club.de>
|
|
|
|
Based on the great feedback to PR #131, I have removed the POP
instruction that I added in my previous commit since UserHardFault
never returns.
|
|
When I currently request GDB to dump a hard fault stack, I see
something like this:
(gdb) bt
#0 UserHardFault_ (ef=0x10001fb8) at /depots/cortex-m-rt/src/lib.rs:537
#1 0x08003fe6 in HardFault ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
GDB can't unwind past HardFault since the current implementation of
this function overwrites the Link Register (LR) value. This change
pushes LR and R0 (to maintain 8-byte stack alignment) to the stack
before transferring execution to UserHardFault().
After this change, I see a callstack like this from GDB:
(gdb) bt
#0 UserHardFault_ (ef=0x10001fb0) at /depots/cortex-m-rt/src/lib.rs:537
#1 0x08003fe8 in HardFault ()
#2 <signal handler called>
#3 0x08002820 in core::ptr::read_volatile (src=0x48001800) at libcore/ptr.rs:472
#4 0x080001a2 in main () at src/07-registers/src/main.rs:14
Notes:
* This code uses 8 more stack bytes.
* Increases the size of the HardFault handler by 2 narrow instructions
or 4 bytes. This could be decreased to 2 bytes by removing the pop
since UserHardFault() doesn't currently return but it just looks too
odd for me to do as an initial attempt.
|
|
|
|
118: [RFC] Keep `.stack_sizes` r=japaric a=japaric
PR [rust-lang/rust#51946] will add a `-Z emit-stack-sizes` to `rustc` that can
be used to (make LLVM) emit stack usage metadata. Most linkers will discard this
metadata by default, however.
[rust-lang/rust#51946]: https://github.com/rust-lang/rust/pull/51946
This PR / RFC proposes that we modify our linker script to keep this metadata
and place in an output `.stack_sizes` section (the canonical section name that
LLVM uses for this metadata).
This `.stack_sizes` section will be marked as `(INFO)` meaning that it won't be
loaded into the Flash or RAM of the target device.
The advantage of doing this is that tools that parse this information will work
out of the box. See examples at the bottom.
Not doing this means that users will have to mess with linker scripts and tweak
the linking process to be able to access the stack usage metadata. See [this
example] to get an idea of the required steps to keep the metadata information.
[this example]: https://github.com/japaric/stack-sizes#example-usage
# Examples
Using the [`cargo stack-sizes`] subcommand to build a project and print its
stack usage information. Assumes that this PR has been merged.
[`cargo stack-sizes`]: https://github.com/japaric/stack-sizes
``` console
$ cargo stack-sizes --bin app -v
RUSTC=stack-sizes-rustc "cargo" "rustc" "--bin" "app" "--"
Finished dev [unoptimized + debuginfo] target(s) in 0.01s
"stack-sizes" "target/thumbv7m-none-eabi/debug/app"
address stack name
0x00000416 112 <cortex_m_rt::ExceptionFrame as core::fmt::Debug>::fmt::h4362577979112554
0x0000059e 96 <<cortex_m_rt::ExceptionFrame as core::fmt::Debug>::fmt::Hex as core::fmt::Debug>::fmt::hd24e21694d63c2ec
0x0000069c 72 core::fmt::Arguments::new_v1_formatted::hc22bfa5fcec35f0e
0x00000758 48 r0::init_data::hdc91f9605f364aeb
0x00000710 40 r0::zero_bss::h24ed73bae17eec88
0x000007d8 24 core::ptr::<impl *mut T>::offset::h940561014e707589
0x000007fc 24 core::ptr::<impl *const T>::offset::h6847f0bc0fe1f0b5
0x00000820 24 core::ptr::read::ha83613479c1b8688
0x00000858 24 core::sync::atomic::compiler_fence::h89dd3725007a5019
0x00002cb0 24 core::sync::atomic::compiler_fence::h4e6eb311378b7447
0x00000668 16 UserHardFault_
0x000007be 16 core::ptr::write_volatile::h92be4be56d39953d
0x00000840 16 core::ptr::write::h1bff45e7fbd786f1
0x00002c92 16 rust_begin_unwind
0x00000404 8 main
0x0000061c 8 Reset
0x00000684 8 SysTick
0x000006fc 8 core::ptr::drop_in_place::h96b0344554e68fcb
0x0000089c 8 core::mem::uninitialized::hea41370061be039b
0x000008aa 8 core::mem::zeroed::h87926bff0ea7d7b3
0x00000400 0 app::main::hb1f6f4352b7a35e2
0x0000069a 0 __pre_init
```
``` console
$ cargo stack-sizes --bin app --release -v
RUSTC=stack-sizes-rustc "cargo" "rustc" "--bin" "app" "--release" "--"
Finished release [optimized + debuginfo] target(s) in 0.01s
"stack-sizes" "target/thumbv7m-none-eabi/release/app"
address stack name
0x00000400 0 main
0x00000402 0 Reset
0x00000616 0 UserHardFault_
0x00000618 0 SysTick
0x0000061a 0 __pre_init
```
---
r? @rust-embedded/cortex-m does this seem like a reasonable addition? Or do you think keeping .stack_sizes should *not* be done in this crate?
Co-authored-by: Jorge Aparicio <jorge@japaric.io>
|
|
|
|
128: Add qemu example and run in CI r=japaric a=sekineh
As @japaric has suggested I ported `lm3s6965evb/src/main.rs` into `example/qemu.rs`.
All errors were fixed, ~but qemu never exits automatically~ `qemu` prints text and exits.
```
sekineh@sekineh-VirtualBox:~/cortex-m-rt_me$ cargo run --example qemu --target thumbv7m-none-eabi
Compiling cortex-m-rt v0.6.3 (file:///home/sekineh/cortex-m-rt_me)
Finished dev [unoptimized + debuginfo] target(s) in 0.17s
Running `qemu-system-arm -cpu cortex-m3 -machine lm3s6965evb -nographic -semihosting-config enable=on,target=native -kernel target/thumbv7m-none-eabi/debug/examples/qemu`
x = 42
sekineh@sekineh-VirtualBox:~/cortex-m-rt_me$
```
## supported targets
- thumbv6m-none-eabi
- thumbv7m-none-eabi
## code size
~code size is 0, which is apparently wrong:~
```
sekineh@sekineh-VirtualBox:~/cortex-m-rt_me$ size target/thumbv7m-none-eabi/debug/examples/qemu
text data bss dec hex filename
10776 0 0 10776 2a18 target/thumbv7m-none-eabi/debug/examples/qemu
```
## code size (original)
(deleted; different compiler version)
Co-authored-by: Hideki Sekine <sekineh@me.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
and switch to the recommended way to parse tokens: `parse_macro_input!`.
This improves (?) error messages when the user applies one of our attributes to
an item that's not a function.
Consider
``` rust
#[entry]
static MAIN: () = ();
```
The error message changed from:
```
error: custom attribute panicked
--> src/main.rs:10:1
|
10 | #[entry]
| ^^^^^^^^
|
= help: message: `#[entry]` must be applied to a function: ParseError(Some("failed to parse fn item: failed to parse"))
```
to:
```
error: expected `fn`
--> src/main.rs:11:1
|
11 | static MAIN: () = ();
| ^^^^^^
error: aborting due to previous error
```
|
|
|
|
- taken from japaric/lm3s6965evb
|
|
See:
https://github.com/japaric/lm3s6965evb/blob/9eeea58826438e84d89e9691a1bb0f85b03d377c/memory.x#L4-L5
|
|
|