aidan63 / hxcppdbg Goto Github PK

A pause on entry option should be provided. The source maps will probably need to be updated to store the entry point so we can place a one shot breakpoint on the first line in that function.

A lot of the complex driver specific frame mapping code could be simplified if we read back from the _hx_stackframe object. This object contains the haxe current function we're in as well as the class and line number. gencpp may need to be modified so the HXLINE isn't on the same line as the actual generated cpp so adding breakpoint remains easy.

Most other languages treat curly brackets as someting what can be stepped onto, currently curly brackets are ignored. This could be tricky as haxe doesn't require curly brackets, so the sourcemap may need to be enhanced to store information on curley brackets.

Anon objects appear to report the wrong number of fields, I think this might be related to non-fixed fields.

The sourcemap should store attributes like final, static, member, etc, so that information can be provided in DAP responses.

All integer and floats regardless of their size are stored in the same ModelData enum constructor. This means Int64s get truncated and there is no proper structured view of native integers. Might want an optional size argument in the model, where if there is none it a haxe integer / float.

enum IntSize {
    UInt8;
    SInt8;
    UInt16;
    ....
    Unspecified
}

ModelData.MInt(v : haxe.Int64, s : IntSize)

The model should also handled odd types like char, wchar_t, etc.

The cpp.Int64Map type is missing visualisation.

By removing use of these two haxe objects the dbgeng driver could be moved into its own files build xml instead of the haxe one.

Currently exceptions cause the debugger to always break, an option to ignore first chance exceptions should be given to pause only on unhandled exceptions.

Threads should be split into "Haxe" and "Native" threads. There are two ways we could go about detecting this.

1. Scan the stack of a thread and see if it starts at the HxThread function.
2. Read the hxcpp thread storage and compare thread IDs against that structure.

Currently cpp types such as cpp.ConstPointer, cpp.Pointer, etc don't have visualisers so will be treated as native objects. Should be easy enough to transform these into just pointers.

Ideally the stdin, stdout, and stderr could be captured so it can be sent through DAP events. This doesn't seem easy to do with DbgEng, haven't checked LLDB yet.

DbgEng seems to model most function arguments wrapped in pointers. We need to provide typed function arguments in the sourcemap so we know how many (if any) levels of de-referencing we need to perform to get the actual object.

Breakpoints should be able to have conditions applied to them, e.g.

• Specific expression evaluates to true.
• Breakpoint has been hit a specific number of times.

Currently classes, arrays, and anon objects are the only supported types for keying into dynamic maps in the evaluator. Ints, Floats, and Maps should be supported as keys.

At somepoint name mapping has stopped working. You now see the managed name for objects / variables and need to use the managled name in the evaluator.

Having information such as stack frames, threads, etc, readable in the evaluator could be useful. Maybe some sort of singleton hxcppdbg.Debugger object, the debugger may want to start to have a concept of the "current thread" which is the thread that caused the last debugger break.

Current DAP implementation uses TTY to read the stdio, this works on Linux but fails on Windows. Quick tests show libuv pipes should be used instead of TTY.

Static variables are currently unsupported. Ideally these would be displayed in several ways.

• For DAP, a new "statics" scope which contains all statics for type which is calling the current top of stack function.
• For DAP, when expanding a class statics should be shown along side member variables.
• In the evaulator by typing a fully qualified type name followed by the static name (e.g. myPackage.MyClass.myStatic)

Currently the type of generic arguments are just ?. The sourcemap should be updated so that the type of generic arguments are stored. We can't really read this back from the target easily, as all generics get converted to Dynamic and its then hard to differenciate between an array of dynamic and an array of a specific class object.

Since that library is already used and has its own Result type that should be used instead of whats essentially a duplicate we currently have.

When running outside of socket mode requests and responses should be logged to a file for easier debugging.

Even if the context is destroyed we cannot start a new session without restarting the entire debugger. The issue appears to be that GetRootNamespace in DbgModel returns null on the second start. This is mainly an issue for wanting to write a test suite.

Simplify the data model by removing Dynamic since we know the runtime type anyway.

Currently the data model doesn't exist for the LLDB driver, this is a pain because the LLDB API is very lacking in this department compared to DbgModel. Best chance is probably to to dip into the LLDB internals and sub-class the SyntheticChildrenFrontEnd and SyntheticChildrenProviderFrontEnd classes.

In many cases a single "haxe" step in results in many "native" step ins (string allocations, boxing, GC collection, etc). If we are stepping into a haxe function and we find ourselves in the hxcpp internals we could immediately step out instead of repeatedly stepping in until we get out again.