microsoft/MIEngine

GDB Server stopOnEntry broken on embedded systems

trond-snekvik opened this issue · 0 comments

GDB servers will always halt execution when the GDB Client attaches. MIEngine attempts to mask this through the EntryPointHit logic in HandleBreakModeEvent. #557 adds a heuristic to determine whether the break event is caused by this attach halt by checking whether the break event occurs inside a file:

// MinGW sends a stopped event on attach. gdb<->gdbserver also sends a stopped event when first attached.
// If this is a gdb<->gdbserver connection, ignore this as the entryPoint
else if (IsLocalLaunchUsingServer())
{
// If the stopped event occurs on gdbserver, ignore it unless it contains a filename.
TupleValue frame = results.Results.TryFind<TupleValue>("frame");
if (frame.Contains("file"))
{
this.EntrypointHit = true;
await this.ClearEntrypointBreakpoint();
_callback.OnEntryPoint(thread);
shouldContinue = false;
}
}

On embedded systems, the target will always be somewhere when the client starts the GDB server, so the "file" field is virtually always populated, even if the target is just halted at the start of its reset procedure. This breaks the "file" heuristic in the snippet above, and the entry breakpoint is deleted before it's hit.

This file based heuristic appears to be an inaccurate way to determine whether the break event is related to attach.

I'd be happy to make a PR with a fix, but I think there are multiple approaches here, and I don't really know which one would be appropriate:

  1. Remove the file based heuristic altogether, and always skip break events without a reason field before the entry point when launching with a server.
  2. Add a member flag that forces the debugger to skip this first break event when launching with a GDB Server instead of looking at the file field
  3. Add some special handling for embedded systems, as their environment is a little different.

Related issues and PRs: