fix/initCommands

[andy9a9]

Move the initCommands to be executed before attaching to target. The current behavior described in documentation is misleading: commands sent before attaching to inferior. The commands are sent after the GDB is attached, which is too late, especially if you wanted to set e.g. the baudrate. The preRunCommands should be executed after the connection to target.

Closes #432

[jreineckearm]

Thanks for creating this PR, @andy9a9 . I believe this needs a bit more discussion. Can you please create an issue first?

I am keen to hear others' opinions (@jonahgraham , @asimgunes), but I believe changing this will break a lot of existing setups:
I agree that implementation and documentation diverge in this case. But based on the current behavior, people debugging embedded systems may have used it to configure the (remote) target system after connecting to the GDB server but before loading any program files. This sometimes is necessary to unlock a device or to setup memories, clocks, etc.

To keep the disrupt for users low I'd suggest to rather fix the documentation and add another set of initialization commands executed before connection (maybe preConnectCommands ?).

I'd suggest to create an issue and discuss there first before driving forward this implementation.

[jreineckearm]

Thanks for raising #432 , @andy9a9 ! Let's continue the discussion there.

[cwalther]

Out of curiosity regarding your process, with respect to my further contributions, what is the advantage of opening a separate issue for discussion, instead of discussing here in the pull request? Should I in the future open both an issue and a pull request for things which I already have a proposed solution for, but that may still require discussion?

[jreineckearm]

Out of curiosity regarding your process, with respect to my further contributions, what is the advantage of opening a separate issue for discussion, instead of discussing here in the pull request? Should I in the future open both an issue and a pull request for things which I already have a proposed solution for, but that may still require discussion?

Main reason is to spare disappointment and time if the proposed solution isn't accepted. And it helps to avoid multiple people working on the same things in parallel without knowing about each other.

Also, the level of discussion normally varies between issue and PR. Where the latter is normally much more implementation than problem focused. So, such separation can have advantage when doing archaeology on past feature and/or design decisions.
I agree though that this is unnecessary overhead when fixing typos or small things that are not user visible features/behavior.