QEMU debugging updates

[blelem]

Addressing a few issues:
Fixes #237, Fixes #234, Fixes #217

The biggest issue this PR is addressing is correcting the "debugging QEMU with GDB" section that really didn't work with latest ARM toolchain (on my setup), because of two things:

• gdb didn't map the rust libcore functions properly. For example, after connecting to a QEMU instance, it did not show the current PC to be on the Reset function, but some random method.
• gdb didn't step over (next), after breaking at main. It just ran to the end of the program.

The user is now instructed to disable the LDD and use the GNU ARM linker instead, which addresses the issues with the mapping.

And instead of doing a simple, break main which did not allow the user to step over after hitting the breakpoint, the user is now guided to do a more complicated,
break hello::__cortex_m_rt_main. After hitting that breakpoint, the next and step commands are working as one would expect.

I am no expert in embedded rust, so the proposed solution may not be optimal, but I think they are better than the current instructions provided by the book which are not working at all on my setup. (Windows 10, with latest versions of QEMU, ARM toolchain, Rust)

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @thejpster (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[adamgreig]

It's still required to have link-arg=-Tlink.x, otherwise the linker script isn't used at all. The user would have to just add linker=arm-none-eabi-ld while keeping link-arg=-Tlink.x.

That said, I'm not sure why changing linker helps in this case anyway, which might be worth a little more investigation.

[jonas-schievink]

I've seen a handful of bugs where LLD messes up debuginfo sections, but I don't think we should recommend GNU LD by default because of that. LLD is the default Rust linker for thumb targets.

[blelem]

I don't know how much the debug info is messed up. The application compiled with LLD works, stepping through the code with gdb works, at least for that minimalist hello world.
So perhaps it's enough for the time being to just signal in the book the bug with smtg like:

once connected to the remote qemu, gdb should indicate that it is paused at the reset() function, waiting for your input.
Reset () at $REGISTRY/cortex-m-rt-0.6.1/src/lib.rs:473

However in some setup, gdb may instead emit some warnings like : core::num::bignum::Big32x40::mul_small () at src/libcore/num/bignum.rs:254 254 src/libcore/num/bignum.rs: No such file or directory.
You can safely ignore those warnings.

I can file a bug for that linker issue, I would appreciate your help if you can suggest where the bug should be filed.

[blelem]

I updated the PR, removing the paragraph recommanding to switch to the GNU LD.

I added some text hinting at the possible debuginfo mix-up glitch, and that it can be safely ignored.

[adamgreig]

Technically, the name __cortex_m_rt_main is an implementation detail of cortex-m-rt and probably shouldn't be relied on for this. I'm not sure if there's any other symbol we could use for a breakpoint, though.

[blelem]

If exposing that implementation detail is not desired, I believe this slightly more verbose version would work well for first time users:

list main

This will show the source code, from the file examples/hello.rs

6       extern crate panic_halt;
7
8       use cortex_m_rt::entry;
9       use cortex_m_semihosting::{debug, hprintln};
10
11      #[entry]
12      fn main() -> ! {
13          hprintln!("Hello, world!").unwrap();
14
15          // exit QEMU

We now would like to add a breakpoint just before the "Hello, world!", which is on line 13. We do that with the break command:

break 13

[blelem]

I updated the PR, replacing setting up a breakpoint at the main symbol with a gentle "set your breakpoint on line 13". I think this way of doing will work well for people following this text.

[adamgreig]

Thanks for this PR! Generally your changes look good but I want to be sure of what's going on before merging the recommendation to use GCC LD or that specific breakpoint name. Others from @rust-embedded/cortex-m might have a better idea...

[adamgreig]

Thanks for the update!

bors merge

[bors]

Build succeeded:

• continuous-integration/travis-ci/push