-
-
Notifications
You must be signed in to change notification settings - Fork 7
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
Propose new Portable PDB related protocol fields #13
Conversation
We have discussed this previously but the entries in With the portable PDB situation it's odd now because the The proposal here to introduce a |
I would also prefer to describe the debug companion ( |
text/0013-portable-pdb.md
Outdated
|
||
We propose to add the following to the [Stack Trace Interface Frame Attributes](https://develop.sentry.dev/sdk/event-payloads/stacktrace/#frame-attributes): | ||
|
||
- `instruction_offset: Number`, as it is currently used by the `sentry-dotnet` SDK. |
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.
instruction_offset
is a good generic name for such a field in principle. Given that the old fields for this have been long removed and were inactive, there is no risk of collisions.
If we want to be more specific, we could also name this something like function_offset
, which would further differentiate the semantics of this field to WASM's addressing mode.
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.
How about this:
- there is a field
instruction_addr
. - there is a field
addr_mode
which may beabs
orrel:n
. - there is an optional field
function_index
(name subject to change).
instruction_addr
is then interpreted as follows:
addr_mode = abs
:instruction_addr
is an absolute addressaddr_mode = rel:n
andfunction_index
is missing:instruction_addr
is relative to modulen
(the WASM case)addr_mode = rel:n
andfunction_index = k
:instruction_addr
is relative to functionk
in modulen
(in other words, an IL offset)
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 don't hate this but I wonder if we then don't want to have a funcrel:n:m
where n
is the module index and m
is the function index?
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.
We were also talking about that last week, and did not really like it because it was too "stringly typed". And parsing things from a specially formatted string is strictly worse than just having proper JSON properties for it.
However I do recognize that the whole problem boils down to having a properly discriminated union:
enum Addr {
Absolute(u64),
ModuleRelative { module_idx: u32, addr: u64 },
FunctionRelative { module_idx: u32, function_idx: u32, addr: u64 },
}
I have researched the Here are the headers:
I can also fetch all three files from the Microsoft symbol server using the
The Looks like the |
The Maybe it is a a different kind of MSF PDB? Either way, it does not look like we can use it at all. |
This adds new fields to the Stack Frame and Debug Image protocol types, and expends the documentation on others. The fields are specific to .NET symbolication using Portable PDB debug files. [RFC0013](getsentry/rfcs#13) introduces and explains these new fields.
Summary
Next StepsI believe we can merge the RFC and the PR to relay right away. The PR to sentry can also be merged, but will only take effect once the That leaves the dotnet SDK as the last piece of the puzzle. My PR works, but does need some work. Also the current SDK architecture is not well suited to write out stack frames and debug images "atomically" at the same time. |
This adds new fields to the Stack Frame and Debug Image protocol types, and expends the documentation on others. The fields are specific to .NET symbolication using Portable PDB debug files. [RFC0013](getsentry/rfcs#13) introduces and explains these new fields.
…#39610) - This will allow `sentry-cli` to upload Portable PDB debug files. The companion PR is getsentry/sentry-cli#1345. - It also allows symbolicator to query/download Portable PDB files. - The PR also adds support for the protocol types specified in [RFC 0013](getsentry/rfcs#13) Co-authored-by: Arpad Borsos <arpad.borsos@sentry.io>
This adds new fields to the Stack Frame and Debug Image protocol types, and expends the documentation on others. The fields are specific to .NET symbolication using Portable PDB debug files. [RFC0013](getsentry/rfcs#13) introduces and explains these new fields.
…#39610) - This will allow `sentry-cli` to upload Portable PDB debug files. The companion PR is getsentry/sentry-cli#1345. - It also allows symbolicator to query/download Portable PDB files. - The PR also adds support for the protocol types specified in [RFC 0013](getsentry/rfcs#13) Co-authored-by: Arpad Borsos <arpad.borsos@sentry.io>
This RFC proposes to add new fields to the event protocol to support symbolication of .NET stack frames that use Portable PDB debug files.
Rendered RFC