LLDB Remote implementation + fixes

[hermansimensen]

Adds remote debugging functionality to LLDB backend similar to existing GDB implementation.
Adds Remote debugging UI that contains the following:

• IP and port fields
• Optional ELF/Symbol file field
• (On GDB only) Optional GDB Executable field
• Hardware breakpoint checkbox.

The GDB executable field is required, because unlike lldb, gdb might require a different executable to debug certain targets. e.g arm-none-eab-gdb. Without this, breakpoint size might be wrong, and it will attempt to read invalid memory regions.

There is also a fix in here for incrementing breakpoint counters on both LLDB and GDB backend.
Also contains a file path fix for windows/windows remote debugging.

Remote debug was tested on both backends against a Raspberry Pi Pico 2W through OpenOCD.

[bfiete]

I haven't looked at the code yet, but just looking at the UI: let's say you are running on Windows- how do you select between connecting to a remove LLDB instance and a remote GDB instance?

Also, there's two ways to connect to GDB: GDB over SSH (where you spawn the gdb+executable through SSH), and GDB Server (which requires the GDB instance already be running). This GUI only seem to cover GDB server.. right?

[hermansimensen]

I haven't looked at the code yet, but just looking at the UI: let's say you are running on Windows- how do you select between connecting to a remove LLDB instance and a remote GDB instance?

Also, there's two ways to connect to GDB: GDB over SSH (where you spawn the gdb+executable through SSH), and GDB Server (which requires the GDB instance already be running). This GUI only seem to cover GDB server.. right?

The debugger being used depends on the debuggerKind setting in the preferences menu. I thought this would be the cleanest approach.

You are right, I have not accounted for ssh connection in this menu. I need to think a bit about how that would look. Do you have any suggestions? Perhaps a tabbed pane approach would be the best?

[bfiete]

Well, the debugger kind in the preferences menu refers to your default native debugger. This is a value that should (theoretically) never need to be changed by the user, and the user does not even need to be aware of which native debugger they are using "under the hood".

When you are remote debugging, however, your need to be able to select your specific debugger (and connection method) because you need to coordinate on the remote side. Note that our custom native Windows debugger does not currently support remote debugging, but it COULD in the future... which would give Windows the ability to remote debug via at least 4 different methods.

I think the right way to do the UI would be to take inspiration from the "Generate File..." dialog, which first lets you select a "Generator" and the populates the UI below that based on the generator you select, showing only the fields required for that specific method.

Also, when showing path fields I think we need to be clear about whether the paths are local paths or remote paths. For local paths, we should use the "..." buttons (using the PathEditWidget class, like the "Add New Project..." selection from the Workspace right-click menu).

[hermansimensen]

Alright. Sounds good. I'll mock up a few UI changes soon.

[hermansimensen]

The menu now features a dropdown box where you can select the desired method of connection, which also allows for adding future methods (i.e native remote debugger).

Also adds the option for gdb over SSH, although I haven't been able to test this feature, other than making sure the generated string for OpenFile is correct.

Have a look and see if you think this design is better.