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

[wasm][debugger] Return errors from debugger.c's details functions #30

Closed
wants to merge 26 commits into from

Conversation

radical
Copy link
Owner

@radical radical commented Jul 1, 2020

No description provided.

@radical
Copy link
Owner Author

radical commented Jul 1, 2020

/cc @lewing
Created here for now, to make review easier, as it is based on the other PRs

radical added 23 commits July 6, 2020 10:36
- this will be useful in upcoming commits, which will need to use the
names for local pointer vars
.. 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
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.
.. 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.
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.

1 participant