Skip to content

Unable to debug application when using library version 0.7.0 #309

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wbuck opened this issue Dec 11, 2020 · 6 comments
Closed

Unable to debug application when using library version 0.7.0 #309

wbuck opened this issue Dec 11, 2020 · 6 comments
Labels
bug nominated Issue nominated as discussion topic for the Embedded WG meeting

Comments

@wbuck
Copy link

wbuck commented Dec 11, 2020

First, I'am able to successfully flash the STM32F303x and run the application.
The issue I'm facing is attempting to debug the application with GDB/OpenOCD.

When issuing a cargo run I see the following messages (emphasis mine):

Reading symbols from target/thumbv7em-none-eabihf/debug/app...
DW_FORM_strp pointing outside of .debug_str section [in module /Users/Me/Projects/embedded_template/target/thumbv7em-none-eabihf/debug/app]

(No debugging symbols found in target/thumbv7em-none-eabihf/debug/app)

As a result I'am unable to set break points or use layout src in GDB.
This only occurs when using cortex-m version 0.7.0.

If I use version 0.6.4 I'am able to successfully debug the application.

Aside from the memory.x file is there additional configuration needed for the newest version of the library?
Are specific versions of the library only compatible with specific MCU's?
Does the version of the cortex-m library require a specific version of GDB?

Below is my memory.x file if it helps:

MEMORY
{
    CCRAM : ORIGIN = 0x10000000, LENGTH = 8K
    FLASH : ORIGIN = 0x08000000, LENGTH = 256K
    RAM : ORIGIN = 0x20000000, LENGTH = 40K
}
_stack_start = ORIGIN(CCRAM) + LENGTH(CCRAM);
@pozix604
Copy link

I'm able to reproduce.

@adamgreig adamgreig added the nominated Issue nominated as discussion topic for the Embedded WG meeting label Jan 19, 2021
@jonas-schievink
Copy link
Contributor

jonas-schievink commented Jan 19, 2021

This seems to be an upstream issue, it is fixed on nightly Rust versions.

EDIT: It only seems fixed when passing -Clinker-plugin-lto to the compiler

@wbuck
Copy link
Author

wbuck commented Jan 19, 2021

OK great, thanks @jonas-schievink

bors bot added a commit that referenced this issue Jan 25, 2021
318: Use LTO instead of removing the panic handler manually. Closes #309 r=jonas-schievink a=adamgreig



Co-authored-by: Adam Greig <[email protected]>
@bors bors bot closed this as completed in 4c624da Jan 25, 2021
@wbuck
Copy link
Author

wbuck commented Jan 25, 2021

@jonas-schievink so to be clear if I pass -Clinker-plugin-lto to the compiler I should be able to use version 0.7? Or should I wait for version 0.7.1 to be released?

@adamgreig
Copy link
Member

This is now fixed by the new 0.7.1 release (containing #318).

@adamgreig
Copy link
Member

@jonas-schievink so to be clear if I pass -Clinker-plugin-lto to the compiler I should be able to use version 0.7? Or should I wait for version 0.7.1 to be released?

Hopefully 0.7.1 solves the issue! Thanks for reporting the bug, sorry we couldn't get it fixed sooner.

adamgreig pushed a commit that referenced this issue Jan 12, 2022
309: Forward-port v0.6.12/13 changelog r=adamgreig a=jonas-schievink

Fixes rust-embedded/cortex-m-rt#299

Co-authored-by: Jonas Schievink <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug nominated Issue nominated as discussion topic for the Embedded WG meeting
Projects
None yet
Development

No branches or pull requests

4 participants