-
-
Notifications
You must be signed in to change notification settings - Fork 49
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
feat(wasm): WASM support #301
Conversation
Co-authored-by: Arpad Borsos <arpad.borsos@sentry.io>
Alternative proposal would be to send |
@jan-auer based on the conversation today about the problem with the address having two modes I tried a few options now and I did not feel happy with most of them. Things I tried:
I ultimately find that from the source code and external API the The benefit though is that it's a more robust API because you always get addresses back, worst case they are of a different kind. This is preferred over someone now getting back things that are not addresses at all (eg: I have an alternative sitting around that replaces the The version I like least was two attributes for addresses. That makes everything really confusing and ugly both in code and API. I ended up changing |
@jan-auer This is ready for review now I believe. |
Now that I'm also looking at the changes in Sentry I'm thinking we should not serialize out |
Actually for symbolicator I think it makes sense to always be explicit and send the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! A number of nitpicks, but this is G2G from my end.
metric!(counter("relative_addr.underflow") += 1); | ||
return Err(FrameStatus::MissingSymbol); | ||
// get the relative caller address | ||
let relative_addr = if let Some(addr) = lookup_result.relative_addr { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Since SymcacheLookupResult
is now a thing, this could become a method on the result type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried this now but it takes too many args. Hmm
Instructions and example for changelogPlease add an entry to
To the changelog entry, please add a link to this PR (consider a more descriptive message): - WASM support. ([#301](https://github.com/getsentry/symbolicator/pull/301)) If none of the above apply, you can opt out by adding #skip-changelog to the PR description. |
Commit 2a19481 (part of getsentry#301) changed the `SourceLookup::get_object_index_by_addr` function to return a stable module index value, independent of the inner Vec's ordering. This updates the debug sessions collection to be keyed on the same module index.
Commit 2a19481 (part of getsentry#301) changed the `SourceLookup::get_object_index_by_addr` function to return a stable module index value, independent of the inner Vec's ordering. This updates the debug sessions collection to be keyed on the same module index.
This implements WASM support to tackle #300. It uses a slightly modified protocol where a sender can supply an
addr_mode
to be explicit about the addressing mode."abs"
is the default absolute addressing mode, another option now isrel:index
with the index of a module in which case the instruction address is considered to be module relative. This change also now lets existing users benefit of this by providing the relative address within any other debug module as alternative.