Skip to content
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

esp-backtrace: Add coredump feature #2672

Open
wants to merge 11 commits into
base: main
Choose a base branch
from

Conversation

bjoernQ
Copy link
Contributor

@bjoernQ bjoernQ commented Dec 4, 2024

Thank you for your contribution!

We appreciate the time and effort you've put into this pull request.
To help us review it efficiently, please ensure you've gone through the following checklist:

Submission Checklist 📝

  • I have updated existing examples or added new ones (if applicable).
  • I have used cargo xtask fmt-packages command to ensure that all changed code is formatted correctly.
  • My changes were added to the CHANGELOG.md in the proper section.
  • I have added necessary changes to user code to the Migration Guide.
  • My changes are in accordance to the esp-rs API guidelines

Extra:

Pull Request Details 📖

Description

Adds the features coredump and coredump-all which will make the panic handler to raise an exception (via ecall/syscall) and changes the exception handler to create a coredump.

Testing

Add the coredump feature to esp-backtrace in examples, change one of the examples to panic.

You can use https://github.com/bjoernQ/espflash-coredump and a recent espfalsh commit (or copy paste, convert from hex to binary)

@bjoernQ bjoernQ marked this pull request as ready for review December 4, 2024 13:12
Copy link
Member

@MabezDev MabezDev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a first round of review, I think I'll have some more thoughts later.

Generally looks good! I'm just wondering whether all the coredump stuff belongs inside esp-backtrace, it looks fairly generic. Maybe it might be better to split it out?

println!("");
println!("");
println!("");
println!("{}", defmt::Display2Format(info));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We shouldn't do this unless we really have to, it pulls in core::fmt machinery

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't new, just the diff is weird.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

writer.writer.write(&reg_info_bytes);
}

pub trait Writer {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we should use embedded-io::Write here instead of defining our own trait? Maybe it makes dumping the core dump through some other means other than serial possible.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was thinking if this is a good idea - only reason to have this trait is the dependency count but I think embedded-io doesn't pull transitive dependencies

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unstable esp-hal already pulls in embedded-io

Copy link
Contributor Author

@bjoernQ bjoernQ Dec 4, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 true - I guess my concerns about increasing build times is not a real world problem in general

@@ -11,6 +11,30 @@ use esp_println as _;

const MAX_BACKTRACE_ADDRESSES: usize = 10;

#[cfg(feature = "esp32")]
const RAM: (u32, u32) = (0x3FFA_E000, 0x4000_0000);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we should define these in esp-metadata, and use them from there. We also have a similar set of const's in the soc module of esp-hal

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's probably a good thing - also depending on esp-metadata is not too bad (in general I'd like to not have too much dependencies here)

@bjoernQ
Copy link
Contributor Author

bjoernQ commented Dec 4, 2024

I'm just wondering whether all the coredump stuff belongs inside esp-backtrace, it looks fairly generic. Maybe it might be better to split it out?

t.b.h. I implemented that functionality in its own library initially (just had features instead of target_arch) and copied the code

I was a bit concerned about a bump in build time (same reason for not using embedded-io and esp-metadata - ok I didn't even think about esp-metadata before :) )

@bjoernQ
Copy link
Contributor Author

bjoernQ commented Dec 5, 2024

I think extracting the coredump generation into its own crate makes sense but where should it live? In the esp-hal repo as esp-coredump? I guess, yes? I don't expect a lot of churn there so it shouldn't be too much of an additional burden. But I can also have it in my personal GitHub space

@bjoernQ bjoernQ force-pushed the esp-backtrace/coredump branch from 61817c6 to 3661c21 Compare December 9, 2024 08:44
@@ -37,6 +37,11 @@ pub(crate) fn psram_range() -> Range<usize> {
}
}

/// The lower bound of the system's DRAM (Data RAM) address space.
const SOC_DRAM_LOW: usize = esp_config::esp_config_int!(usize, "REGION-DRAM-START");
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think (ab)using the esp-config macro should be fine

@@ -75,3 +75,5 @@ symbols = [
"pm_support_touch_sensor_wakeup",
"ulp_supported",
]

memory = [{ name = "dram", start = 0x3FFA_E000, end = 0x4000_0000 }]
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we can and should define all memory regions here later and even use them in e.g. the linker scripts

(But that is definitely out of scope for this PR)

pub const SOC_DRAM_LOW: usize = 0x4080_0000;
/// The upper address boundary for system DRAM.
pub const SOC_DRAM_HIGH: usize = 0x4088_0000;
/// The lower bound of the system's DRAM (Data RAM) address space.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe all of these constants should come from esp-metadata some day

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the idea 👍

@bjoernQ bjoernQ added the skip-changelog No changelog modification needed label Dec 9, 2024
@bjoernQ
Copy link
Contributor Author

bjoernQ commented Dec 9, 2024

skip-changelog because of the not-user-facing changes in esp-hal

@@ -2,7 +2,7 @@
name = "esp-backtrace"
version = "0.14.2"
edition = "2021"
rust-version = "1.76.0"
rust-version = "1.79.0"
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

needed by esp-metadata


// Define env-vars for all memory regions
for memory in self.memory() {
println!(
Copy link
Contributor

@bugadani bugadani Dec 9, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we also generate has_<memory_region>_region config symbols?

@bjoernQ bjoernQ force-pushed the esp-backtrace/coredump branch from c13c544 to ac4b839 Compare December 18, 2024 07:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
skip-changelog No changelog modification needed
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants