this adds an entry2 attribute in the vein of cortex_m_rt::entry. This attribute
lets you safely use `static mut` variables -- they get transformed into
`&'static mut` references. Example:

``` rust
  #[entry2]
fn main() -> ! {
    static mut COUNT: u32 = 0;

    // user code
    let count: &'static mut = COUNT;
}
```

I did something different in this version: instead of using random identifiers I
wrapped the user entry point into a `const` item to make it impossible to invoke
it from software (if that were allowed using the `static mut` would result in
UB).

Just for reference the above code expands into this:

``` rust
const main: () = {
    #[no_mangle]
    fn main() -> ! {
        let COUNT: &'static mut u32 = {
            static COUNT: u32 = 0;

            &mut COUNT
        };

        // user code
        let count: &'static mut = COUNT;
    }
};
```

Not using random identifiers means that we avoid a (host) dependency on the rand
crate.

This change is a breaking change because it bumps the Minimum Supported Rust
Version (MSRV) to 1.31.0 -- this crate current MSRV is 1.30.0. The MSRV needs to
be bumped because `#[no_mangle]` / `#[link_section]` items inside private
items (like the `const` item above) only get the right symbol visibility in Rust
1.31.0 (the visibility rules around `#[no_mangle]` / `#[link_section]` got
changed in that version).

Instead of naming this attribute: `entry2`, we could replace the existing
`entry!` macro but that would be another breaking change.

18: Update docs and bump version r=dvc94ch a=Disasm

cc @rust-embedded/riscv 

Co-authored-by: Vadim Kaushan <admin@disasm.info>

17: Build on stable r=dvc94ch a=Disasm

Closes #14 

cc @rust-embedded/riscv 

Co-authored-by: Vadim Kaushan <admin@disasm.info>

16: Update for newer Rust versions r=dvc94ch a=fintelia

A couple features are now stable as of Rust 1.30, and panic the definition of the panic_fmt lang item is now slightly different.

Co-authored-by: Jonathan Behrens <fintelia@gmail.com>

10: support linking with lld r=dvc94ch a=danc86

Rust now ships an embedded copy of lld, so if we can link crates with lld it will make the getting started experience way smoother (don't need to find a separate GNU ld).

Co-authored-by: Dan Callaghan <djc@djc.id.au>

To work around a bug in lld, we need to avoid starting the .bss section
from a fixed address (previously, the _sbss symbol). Otherwise lld
incorrectly tries to extend the FLASH output region up to the start of
the RAM output region, which is too large.

To work around another bug in lld, we need to avoid starting sections
marked with (INFO) from a specific starting address. Its parser does not
accept both a start address and the (INFO) attribute.

Specifying these start addresses is redundant anyway, the linker will
lay them out in sequential order for us.

The .cfi_* assembler directives cause call frame information to be
emitted in a special .eh_frame section. But this is not needed in the
final binary, because we are not doing panic unwinding.

GNU ld already discards this section with its (default) --gc-sections
behaviour. Lld doesn't do that by default though, instead it complains:

    rust-lld: error: no memory region specified for section '.eh_frame'

So let's explicitly discard the .eh_frame section.

This aligns the VMA (virtual adddress at runtime):

    .rodata ALIGN(4) :
    {
        ...

whereas this aligns the LMA (load address):

    .rodata : ALIGN(4)
    {
        ...

If we ensure the VMA is aligned the linker will keep the corresponding
LMA in sync (and it will be aligned too).

Previously, by forcing the LMA to be aligned but leaving the VMA
unspecified, the linker would split .text and .rodata into two
separate loads because their addresses fell out of sync.

This is no longer necessary now that we can configure the target to
exclude the .debug_gdb_scripts section.
See: https://github.com/rust-lang/rust/pull/53139

This is needed for lld, otherwise it will complain about section flag
mismatch:

    ld.lld: error: incompatible section flags for .text
    >>> target/riscv32imac-unknown-none/debug/deps/libriscv_rt-7850ee1a6233fbe9.rlib(riscv_rt-7850ee1a6233fbe9.4tmuw4s4crjeqbm5.rcgu.o):(.trap): 0x4
    >>> output section .text: 0x6

Matches cortex-m-rt. See:

https://github.com/rust-embedded/cortex-m-rt/pull/69
https://github.com/rust-embedded/cortex-m-rt/pull/78

The #[naked] attribute means Rust won't emit instructions to push and
pop a new stack frame. But the assembly routine which calls _start_rust
also doesn't push a new stack frame, so there is no valid stack for this
function.

We probably need a stack frame though, since it's implemented in Rust
and we can't easily ensure that Rust won't try to allocate any local
variables. See #5.

I'm not sure when this changed, but without this patch the app does not
seem to run, and with it the blinky_delay test app works as expected.

This is also how it looks in cortex-m-rt:
https://github.com/rust-embedded/cortex-m-rt/blob/6c269f195c9a705162fd912beb952b430cc28336/src/lib.rs#L468

In the original riscv-rust fork the target arch was simply named
"riscv", but RISC-V support landed in Rust with "riscv32" as the arch
name instead.

Include "riscv64" optimistically for future-proofing.

This reverts commit 45def528.