Skip to content

support a few DWARF-5 only features #1410

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

Merged
merged 38 commits into from
Apr 27, 2020
Merged

Conversation

ggreif
Copy link
Contributor

@ggreif ggreif commented Mar 26, 2020

See #932.

  • accept and pass DebugAddrIndex, DebugStrOffsetsIndex attributes
  • skip DebugAddrBase, DebugStrOffsetsBase attribute when transforming, these are managed by the compilation unit elsewhere
  • accept and resolve DebugLineStrRef in line programs
  • read .debug_addr
  • read .debug_rnglists
  • read .debug_loclists
  • read .debug_line_str
  • read .debug_str_offsets
  • perform the DebugAddrIndex and DebugStrOffsetsIndex indirections

TODO:

  • tests (added DWARF-5 test, but it needs a refresh, lldb test also needed).

@yurydelendik yurydelendik self-assigned this Mar 26, 2020
@ggreif
Copy link
Contributor Author

ggreif commented Mar 26, 2020

@yurydelendik does your self-assignment mean I shouldn't add any more commits?

@bjorn3
Copy link
Contributor

bjorn3 commented Mar 26, 2020

No, it means that he will review this PR once it is ready.

@ggreif ggreif mentioned this pull request Mar 26, 2020
7 tasks
@ggreif ggreif force-pushed the master branch 2 times, most recently from d8812f4 to 19f932d Compare April 17, 2020 19:35
@ggreif ggreif force-pushed the master branch 2 times, most recently from 7d925db to b26be14 Compare April 20, 2020 21:10
ggreif added 2 commits April 24, 2020 00:26
in order to support these, one has to pass around the references
to their sections too, and to the `unit`, because the str_offsets_base
lives there
ggreif added 4 commits April 24, 2020 19:42
in the line program

now these tests pass:
test debug::translate::test_debug_dwarf_translate ... ok
test debug::translate::test_debug_dwarf5_translate ... ok
@ggreif
Copy link
Contributor Author

ggreif commented Apr 24, 2020

@yurydelendik what about enabling these?

index 1fba1c35c..bba6aef1e 100644
--- a/tests/all/debug/translate.rs
+++ b/tests/all/debug/translate.rs
@@ -25,7 +25,6 @@ fn check_wasm(wasm_path: &str, directives: &str) -> Result<()> {
 }
 
 #[test]
-#[ignore]
 #[cfg(all(
     any(target_os = "linux", target_os = "macos"),
     target_pointer_width = "64"
@@ -58,7 +57,6 @@ check:        DW_AT_decl_line (10)
 }
 
 #[test]
-#[ignore]
 #[cfg(all(
     any(target_os = "linux", target_os = "macos"),
     target_pointer_width = "64"

@yurydelendik
Copy link
Contributor

what about enabling these?

It requires from a developer to have lldb and dwarfdump installed: wasmtime is an umbrella for multiple (sub)project, so we decided to run these tests only on CI.

@ggreif
Copy link
Contributor Author

ggreif commented Apr 24, 2020 via email

@ggreif
Copy link
Contributor Author

ggreif commented Apr 24, 2020

@yurydelendik can you do me a favour and refresh these on my branch with clang-11 (prerelease):
tests/all/debug/testsuite/fib-wasm-dwarf5.wasm tests/all/debug/testsuite/fib-wasm.wasm

The instructions are at the top of the file tests/all/debug/testsuite/fib-wasm.c.

Reason: I don't have a bleeding edge clang, and using older clang-10 doesn't support DW_AT_frame_base yet. This causes test failures.

UPDATE: I added you to my repo collabs.

@ggreif ggreif requested a review from yurydelendik April 25, 2020 15:24
@ggreif
Copy link
Contributor Author

ggreif commented Apr 27, 2020

@yurydelendik I am grappling with remove_incomplete_ranges in expression.rs. Mostly because I cannot find a definition of range and label. This looks like a (boolean) matrix operation where labels must cover ranges, i.e. the whole row.

But somehow labels correspond to local variables, and ranges are in terms of code offsets (IIUC). I end up with all ranges discarded, because

self.processed_labels = {val1, val4294967294} with .len == 2
and p's label_location only mentions one of the variables:

remove_incomplete_ranges iter CachedValueLabelRange { func_index: DefinedFuncIndex(6), start: 0, end: 62, label_location: {} }  ### 0 vs. 2
remove_incomplete_ranges iter CachedValueLabelRange { func_index: DefinedFuncIndex(6), start: 62, end: 96, label_location: {val1: Stack(ss1)} }  ### 1 vs. 2
remove_incomplete_ranges iter CachedValueLabelRange { func_index: DefinedFuncIndex(6), start: 96, end: 120, label_location: {} }  ### 0 vs. 2
remove_incomplete_ranges iter CachedValueLabelRange { func_index: DefinedFuncIndex(6), start: 120, end: 140, label_location: {val4294967294: Stack(ss0)} }  ### 1 vs. 2
remove_incomplete_ranges iter CachedValueLabelRange { func_index: DefinedFuncIndex(6), start: 140, end: 175, label_location: {} }  ### 0 vs. 2

I am obviously doing something wrong, but since I barely understand what is going on here, I am hard-pressed fixing it.

I am also happy to accept a zoom lecture if that is more convenient for you.

@yurydelendik
Copy link
Contributor

I am grappling with remove_incomplete_ranges in expression.rs

Please notice I fixed lots of issues for expression.rs in #1572 -- currently waiting on review.

ValueLabelRangesBuilder is used during DWARF expression transformation, and if not all value labels (in your case 2 labels) present in particular item of ranges, DWARF expression will not be transformed successfully.

@ggreif
Copy link
Contributor Author

ggreif commented Apr 27, 2020

I am grappling with remove_incomplete_ranges in expression.rs

Please notice I fixed lots of issues for expression.rs in #1572 -- currently waiting on review.

ValueLabelRangesBuilder is used during DWARF expression transformation, and if not all value labels (in your case 2 labels) present in particular item of ranges, DWARF expression will not be transformed successfully.

So, next step for me to figure out why not both labels show up in CachedValueLabelRange, right?

@yurydelendik
Copy link
Contributor

So, next step for me to figure out why not both labels show up in CachedValueLabelRange, right?

Correct. Try to use --opt-level 0 maybe it is just cranelift optimization or bug in value label range tracking there.

(BTW, would you like to join https://bytecodealliance.zulipchat.com/ for chat?)

@yurydelendik
Copy link
Contributor

Let's freeze scope of this PR to the original description. I noticed you trying to work on DWARF expressions related stuff. I'll update .wasm tests and will try to finalize the review.

@ggreif
Copy link
Contributor Author

ggreif commented Apr 27, 2020

I was trying to figure out if the Exprloc problems I am experiencing are DWARF-5 related. That's the background of my last Q. Never mind, I think this PR is ready. Please go ahead, and I'll iterate on the Expr stuff with follow-up PRs.

@yurydelendik
Copy link
Contributor

Updated wasm files. fwiw you don't have to provide access to entire repo, submitted as PR branch (option selected by default) gives push access for a reviewer.

clang version 11.0.0 (https://github.com/llvm/llvm-project.git 1090a830692a863ccb091e3fad8cc1a287417493)
Copy link
Contributor

@yurydelendik yurydelendik left a comment

Choose a reason for hiding this comment

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

Looks good. Few items to address before merge.

ggreif added 2 commits April 27, 2020 21:39
review feedback: don't cross-check index bases
@ggreif
Copy link
Contributor Author

ggreif commented Apr 27, 2020

This looks good. Will you squash?

@yurydelendik yurydelendik merged commit 1639ed0 into bytecodealliance:master Apr 27, 2020
@yurydelendik
Copy link
Contributor

Thank you for the patch

@ggreif ggreif mentioned this pull request Apr 28, 2020
1 task
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.

3 participants