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

Debug info for bytecode #1449

Open
Bike opened this issue Apr 1, 2023 · 0 comments
Open

Debug info for bytecode #1449

Bike opened this issue Apr 1, 2023 · 0 comments

Comments

@Bike
Copy link
Member

Bike commented Apr 1, 2023

The bytecode compiler should store enough information for the debugger to be able to figure out where the code is. This probably entails something like DWARF line tables. There should be a map from each VM IP to its source code.

Probably each module has its own map, and when we make a module we register its IP range, similar to what we do for DWARF with object files.

Strictly speaking we only need to map call IPs in most cases. It is possible to asynchronously interrupt the VM, but at the moment it's not clear how to let the debugger figure out the IP from there in any efficient way - most likely we'd have to get the IP variable in bytecode_vm from the actual DWARF. So we can start with just calls and go from there.

As a bonus, it should be possible to also map each IP to a stackmap with information about what VM stack positions correspond to what variables. That's actually easier to do right now since the compiler already tracks that information.

This all will slow the compiler down a bit. We don't really care about debugger speed compared to compiler speed, so the representation should be as easy to dump as possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant