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

Improve error handling in dwarfdump #234

Merged
merged 6 commits into from
Aug 13, 2017
Merged

Improve error handling in dwarfdump #234

merged 6 commits into from
Aug 13, 2017

Conversation

bheisler
Copy link
Contributor

I've changed all of the expect() calls, but I left the unwraps since it doesn't look like there's any way they could actually fail in practice.

I wasn't entirely sure what approach to take here since issue #231 is pretty low on details, so I hope this is OK. If not, let me know what you're looking for and I'll try to fix it up.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 93.998% when pulling 9219f02 on bheisler:master into d9d5e73 on gimli-rs:master.

Copy link
Collaborator

@philipc philipc left a comment

Choose a reason for hiding this comment

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

This is great, thanks for tackling this. I left a few comments for further optional improvements.

print!("{:indent$}{:27} ", "", attr.name(), indent = indent + 18);
if flags.raw {
println!("{:?}", attr.raw_value());
} else {
dump_attr_value(&attr, &unit, debug_loc, debug_ranges, debug_str);
dump_attr_value(&attr, &unit, debug_loc, debug_ranges, debug_str)?;
Copy link
Collaborator

Choose a reason for hiding this comment

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

It would be nice if we printed the error and continued dumping in cases where the error doesn't prevent it, such as here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

How can I tell which errors should continue dumping and which ones shouldn't?

Copy link
Collaborator

Choose a reason for hiding this comment

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

We can continue dumping if the iterator doesn't need the result of the operation to find the next item. That's going to need a bit of knowledge of the internals to figure out though. The main other spot that I think is useful are the loops for debug_info.units() and debug_types.units(). There's possibly a couple more similar to these (anything that uses parse_initial_length internally) but it's not worth spending a lot of time on.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

OK, thanks. I'll take a look at that tomorrow if I have time.

@@ -896,22 +954,22 @@ fn dump_pubnames<R: Reader>(debug_pubnames: &gimli::DebugPubNames<R>,
cu_offset.0,
pubname.name().to_string_lossy().unwrap())
Copy link
Collaborator

Choose a reason for hiding this comment

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

The function is already returning a Result, so I would remove the unwrap here too, even though it can't fail for EndianBuf. It'll get optimized away, and it makes it easier when looking for other places that unwrap. There might be a few more unwraps like this that you could remove too.

};
let file = header.file(file).expect("File index should be valid");
let file = header.file(file).ok_or(Error::MissingFileIndex)?;
Copy link
Collaborator

Choose a reason for hiding this comment

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

We could print an error here instead of returning it.

@@ -633,7 +633,7 @@ fn dump_exprloc<R: Reader>(data: &gimli::Expression<R>, unit: &Unit<R>) -> Resul
Ok(())
}

fn dump_op<R: Reader>(dwop: gimli::DwOp, op: gimli::Operation<R, R::Offset>, newpc: &R) {
fn dump_op<R: Reader>(dwop: gimli::DwOp, op: gimli::Operation<R, R::Offset>, newpc: &R) -> Result<()> {
Copy link
Collaborator

Choose a reason for hiding this comment

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

This function needs Ok(()) at the end now.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Well, that's embarassing. Should be fixed now.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 93.998% when pulling 8c0af2c on bheisler:master into d9d5e73 on gimli-rs:master.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 93.998% when pulling 29a65d8 on bheisler:master into d9d5e73 on gimli-rs:master.

Copy link
Collaborator

@philipc philipc left a comment

Choose a reason for hiding this comment

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

Thanks!

@philipc philipc merged commit 8efbc70 into gimli-rs:master Aug 13, 2017
@bheisler
Copy link
Contributor Author

Thanks for responding quickly. It was a pleasure working with you.

@fitzgen
Copy link
Member

fitzgen commented Aug 13, 2017

@bheisler thanks for the patch :) Interested in hacking on gimli some more? We could use some help with #140 if you're interested

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants