Objdump in Hard Fault Handler Should Drop --release

Open Beginner friendly
#208 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
1/5
Estimated time
Under an hour
Newbie friendliness
68/100
Issue type
Documentation
Clarity
Clearly specified
Activity status
Stale
Tech stack
rust

Research direction

Start in Getting Started → Exceptions → The hard fault handler and review the cargo objdump command alongside the described cargo build flow. Done means the section clearly explains whether --release is needed and gives consistent directions for producing a dump of the debug build.

Written by the indexing model from the issue text.

Description

In the section Getting Started->Exceptions->The hard fault handler, explicit directions are not given to run the program. That is probably acceptable, but I'm assuming most people would have made the changes to memory.x and switch to the last target in .cargo/config and then run openocd like this:

FLASH : ORIGIN = 0x08000000, LENGTH = 256K
RAM : ORIGIN = 0x20000000, LENGTH = 40K

target = "thumbv7em-none-eabihf" # Cortex-M4F and Cortex-M7F (with FPU)

After that they would run openocd. I would expect that "cargo build" would have been expected in another terminal which by default build a debug version. Finally I get to my question:

Shouldn't
argo objdump --bin app --release -- -d -no-show-raw-insn -print-imm-hex
actually be:
argo objdump --bin app -- -d -no-show-raw-insn -print-imm-hex
to create a dump of the debug version just compiled?

If "--release" is left out, the pc of:

ExceptionFrame {
...
pc: 0x08000e00,
xpsr: 0x61000200,
}

matches this:

08000dfa core::ptr::read_volatile::h436b41ad0b34e32b:
8000dfa: sub sp, #0xc
8000dfc: str r0, [sp, #0x4]
8000dfe: ldr r0, [sp, #0x4]
8000e00: ldr r0, [r0]

and once again the ldr is the cause, but not at a ResetTrampoline

Perhaps there should be a small block with compile directions or maybe even a small note stating "--release" is not needed in the objdump if it was compiled in debug - which most people would do when building for use with gdb.

Dominant language
No language data
Stars
1.3k
Forks
223
PR merge metrics
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from rust-embedded/book

All issues in rust-embedded/book

Similar issues

More Documentation issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.