-
Notifications
You must be signed in to change notification settings - Fork 0
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
[wasm][debugger] Return errors from debugger.c's details functions #30
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
/cc @lewing |
- this will be useful in upcoming commits, which will need to use the names for local pointer vars
Based on suggestion from @vargaz
.. breakpoint by method name. Async methods themselves don't have the debug information. Instead, that can be found on the generated async implementation type/method. Here, we just look for a type name starting with `{original_type_name}/<{async_method_name}>`, and use the method `MoveNext` from that.
- We should really be handling invalid object ids, and report errors for those, where appropriate. This will be done in a future PR - For this PR, I'm adding tests that just check that invalid objects, or trying to deref regular objects, doesn't blow up
…n string - addresses review comment from @lewing
test: `DebuggerTests.ValueTypesTest:MethodUpdatingValueTypeMembers`
- In some places we weren't checking for the `description` property - and this hid a bug where sometimes that property wasn't added (eg. for numbers) - Instead, we were working around that by "fixing it up" later - Now, we use the same checks for `Check{Number,String,*}` API, and the `CheckValue/CheckProps` API used with `TNumber` etc. - So, this commit: - fixes the checks, and the tests - and fixes the bug
- these are of the form `dotnet:${scheme}:{id-args-object}` - Examples: - `dotnet:valuetype:{ containerId: 4 }` - `dotnet:valuetype:{ num: 2 }` - the `num` field is autogenerated if no id-args are provided. This gets used when valuetypes are expanded. - `this._id_table [id-string]` has associated property objects for every `id` - This might contain, for example, `klass` pointer, and base64 representation of a valuetype
.. to use a single function to get details of the full array, and individual elements.
- Allow `_new_id` to update properties for existing objectIds - Extract valuetype id assigment code to a separate function
- add some new getters to the test classes - this will become useful in subsequent commits that add support for invoking getters on valuetypes
- this also becomes useful in subsequent commits which enable invoking getters on valuetypes
- keep a copy of the value bytes, and the klass pointer - this allows being able to invoke getters on such a valuetype, at a later point - This allows getters like `DateTime.Date`, which has the type `DateTime`
.. and replace `var` with `let`, or `const`, where appropriate.
radical
force-pushed
the
vt-getters-invoke
branch
from
July 6, 2020 18:52
6789b3e
to
ac31ffd
Compare
.. especially the ones that return data in `MONO.var_info`. To use: 1. `this._register_c_var_fn ('mono_wasm_get_object_properties', 'bool', [ 'number', 'bool' ]);` 2. Now, this function can be called as `this.mono_wasm_get_object_properties_info (.. )` - returns `res` which has the contents of `MONO.var_info`, after running `_fixup_name_value_objects` on it.
- functions like those for getting object/vt properties, can fail, for example, if the objectId is invalid. - We now return that bool result, and that gets surfaced to the caller - This will also help to differentiate the case where the result of such a function was a failure vs just an empty result
- These tests don't actually depend on the error message, and we don't have another to way to differentiate why a command might have failed with an exception. So, right now, they will pass as long as the commands fail as expected. - Future TODO: return `error`, instead of exception details for issues in `mono.js`, like incorrect input, invalid id etc, and update these tests accordingly.
radical
force-pushed
the
vt-getters-invoke
branch
from
July 7, 2020 17:43
ac31ffd
to
9428c6b
Compare
radical
force-pushed
the
vt-getters-invoke
branch
from
July 10, 2020 02:09
9428c6b
to
629799a
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.