Add support for GDB initialization scripts

[ardnew]

These changes add the ability to provide GDB initialization scripts from command-line flags and target JSON files. GDB scripts save a lot of time by being able to automatically configure breakpoints, set auto-display expressions, configuring GDB front-end extensions, etc.

The command-line flag is named -gdbinit and can be specified multiple times for multiple files. It also accepts an optional single-character prefix, - or +, that indicates the file should be executed before or after loading the inferior, respectively. These correspond to GDB command-line flags --init-command, -ix and --command, -x, respectively. If the prefix is not defined, then -, or --init-command, ix, by default.

The JSON key is also gdbinit, of type []string. It follows the same prefix convention as the flag, and if both are provided, the command-line flag takes precedence, overriding the target JSON.

[aykevl]

This looks like a useful functionality. However, I'm not sure it's a good idea to add this to the target config. Is there a case where a target needs some special initial command that can't be added in some other way?

Also, any thoughts on what we should do if (eventually) we might add tinygo lldb in addition to tinygo gdb?

[ardnew]

I imagined removing all of the GDB init commands that are currently hard-coded in main.go (see func FlashGDB), and instead create equivalent default init scripts. These hard-coded commands vary based on the content of the target JSON (the "Programmer" key in particular), and so these default init scripts should be specified per target JSON.

Default init scripts provide a little more control to the user, should they want it, but it doesn't require additional effort from them. They also offer functionality that is currently impossible without modifying TinyGo source code:

1. There is currently no way to attach to a program running on the target because of the above hard-coded commands — they always initiate a load followed with monitor reset.

   • The user has to invoke GDB manually, which requires either a separate tinygo build step or locating the tmp executable created by a previous call to tinygo gdb.
   • In this case, being able to change the GDB init commands lets them use tinygo gdb directly for a more consistent experience.

2. Another case is changing the TCP port used by both gdbserver and gdb. I know I personally cannot use both of my JLink debuggers simultaneously (to compare execution traces of two separate boards) with tinygo gdb because of the port conflict.

   • The solution here again is using GDB manually (again requires to Bring Your Own executable).
   • (Related) TinyGo uses the default TCP port used by other tools. Since other tools usually provide a way to change this, the onus is placed on them to accommodate TinyGo if both are used simultaneously.

There may be others, but these two I know I have personally run into in the past. Thoughts?

---

Since LLDB and GDB scripts/commands are different, I think it makes sense to use two separate flags and JSON keys (i.e., -gdbinit and -lldbinit):

1. There is a bit of overlap between LLDB and GDB. Two separate flags/keys would help prevent the user accidentally providing a GDB script to LLDB or vise-versa, which would likely happen if they shared a flag/key such as -debuginit, -dbgeval, etc.
2. It allows the user to switch which debugger they are using — GDB or LLDB — without having to change which default init script is being used. There is a separate script for both.
   • This, of course, depends on the adoption of default init scripts from my arguments above.