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

fix a bug when applying offset in call stacks information #3194

Merged
merged 1 commit into from
Mar 1, 2024

Conversation

lum1n0us
Copy link
Collaborator

@lum1n0us lum1n0us commented Mar 1, 2024

the offset value is based on start of wasm file. it also equals to the value of wasm-objdump -d

the offset value is based on start of wasm file. it also equals to
the value of `wasm-objdump -d`
Copy link
Contributor

@wenyongh wenyongh left a comment

Choose a reason for hiding this comment

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

LGTM

@wenyongh wenyongh merged commit 1b9fbb1 into bytecodealliance:main Mar 1, 2024
1 check passed
wenyongh pushed a commit that referenced this pull request Mar 5, 2024
- Address values in call stack dump are relative to file beginning
- If running under fast-interp mode, address values are relative to
  every pre-compiled function beginning, which is not compatible
  with addr2line
victoryang00 pushed a commit to victoryang00/wamr-aot-gc-checkpoint-restore that referenced this pull request May 1, 2024
- Address values in call stack dump are relative to file beginning
- If running under fast-interp mode, address values are relative to
  every pre-compiled function beginning, which is not compatible
  with addr2line
victoryang00 pushed a commit to victoryang00/wamr-aot-gc-checkpoint-restore that referenced this pull request May 2, 2024
- Address values in call stack dump are relative to file beginning
- If running under fast-interp mode, address values are relative to
  every pre-compiled function beginning, which is not compatible
  with addr2line

Signed-off-by: victoryang00 <[email protected]>
victoryang00 pushed a commit to victoryang00/wamr-aot-gc-checkpoint-restore that referenced this pull request May 27, 2024
…on (bytecodealliance#3194)

The offset value is based on the start of the wasm file, it also equals to
the value of `wasm-objdump -d <wasm_file>`.
victoryang00 pushed a commit to victoryang00/wamr-aot-gc-checkpoint-restore that referenced this pull request May 27, 2024
- Address values in call stack dump are relative to file beginning
- If running under fast-interp mode, address values are relative to
  every pre-compiled function beginning, which is not compatible
  with addr2line
victoryang00 pushed a commit to victoryang00/wamr-aot-gc-checkpoint-restore that referenced this pull request May 27, 2024
- Address values in call stack dump are relative to file beginning
- If running under fast-interp mode, address values are relative to
  every pre-compiled function beginning, which is not compatible
  with addr2line

Signed-off-by: victoryang00 <[email protected]>
victoryang00 pushed a commit to victoryang00/wamr-aot-gc-checkpoint-restore that referenced this pull request May 27, 2024
- Address values in call stack dump are relative to file beginning
- If running under fast-interp mode, address values are relative to
  every pre-compiled function beginning, which is not compatible
  with addr2line

Signed-off-by: victoryang00 <[email protected]>
@lum1n0us lum1n0us deleted the fix/addr2line_offset branch May 31, 2024 03:19
victoryang00 pushed a commit to victoryang00/wamr-aot-gc-checkpoint-restore that referenced this pull request Jun 7, 2024
- Address values in call stack dump are relative to file beginning
- If running under fast-interp mode, address values are relative to
  every pre-compiled function beginning, which is not compatible
  with addr2line

Signed-off-by: victoryang00 <[email protected]>
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.

2 participants