Mismatch between expected threadId and actual thread ID in stopped event

Description:

In the Debug Adapter Protocol's specification for the Stopped event, the threadId is described as "The thread which was stopped." However, I've encountered an inconsistency between the specified threadId and the actual ID of the thread.

To extract the threadId, I use the following code in my extension:

public onDidSendMessage(m: DebugProtocol.ProtocolMessage) {
    this.routeDebugMessage(m);
}
private routeDebugMessage(m: DebugProtocol.ProtocolMessage): void {
    if (m.type === "event") {
        const e = m as DebugProtocol.Event;
        switch (e.event) {
        case "stopped": {
            const threadID = e.body?.threadId as number;
            // ... other operations
        }
    }
}

The C++ code for my breakpoint is:

// ... some code ...

int main(int argc, char *argv[]) {
  constexpr size_t length = 32;
  // ... other code ...
}

In this context, I received a value of 18888 for threadId instead of the expected 1 as shown by the -exec info threads command:

  Id   Target Id                                           Frame 
* 1    Thread 0x7ffff59b15c0 (LWP 18888) "array-transform" main (argc=..., argv=...) at array-transform.cpp:27

From my observations, it seems that the LWP (Light-Weight Process) value is being used instead of the actual thread ID, leading to potential confusion and issues.

This discrepancy is also visible in the MI log:

1: (3018) <-1019-exec-run
1: (3020) ->=thread-group-started,id="i1",pid="18888"
1: (3020) ->=thread-created,id="1",group-id="i1"
1: (3024) <-1020-thread-info 1
1: (3040) ->=library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1",ranges=[{from="0x00007ffff7fd0100",to="0x00007ffff7ff2684"}]
1: (3045) ->1019^running
1: (3045) ->*running,thread-id="all"
1: (3045) ->(gdb)
1: (3045) 1019: elapsed time 27
1: (3046) ->~"Stopped due to shared library event (no libraries added or removed)\n"
1: (3046) ->*stopped,reason="solib-event",thread-id="1",stopped-threads="all",core="111"
1: (3047) ->(gdb)
1: (3047) ->1020^done,threads=[{id="1",target-id="process 18888",name="array-transform",frame={level="0",addr="0x00007ffff7fd2fd1",func="??",args=[],from="/lib64/ld-linux-x86-64.so.2",arch="i386:x86-64"},thread-group="i1",state="stopped",core="111"}]
1: (3047) ->(gdb)

blablabla

Breakpoint 1, main (argc=..., argv=...) at array-transform.cpp:27
27	  constexpr size_t length = 32;
1: (3539) <-1027-thread-info
1: (3540) ->1027^done,threads=[{id="1",target-id="Thread 0x7ffff59b15c0 (LWP 18888)",name="array-transform",frame={level="0",addr="0x0000000000404819",func="main",args=[{name="argc"},{name="argv"}],file="array-transform.cpp",fullname="/home/user/array-transform/src/array-transform.cpp",line="27",arch="i386:x86-64"},thread-group="i1",state="stopped",core="111"}],current-thread-id="1"
1: (3540) ->(gdb)
1: (3541) 1026: elapsed time 35
1: (3543) 1027: elapsed time 4

Expected Behavior:

The threadId in the Stopped event should match the actual thread ID as per the Debug Adapter Protocol's specification.

Actual Behavior:

The threadId in the Stopped event is reflecting the LWP value instead of the actual thread ID.

Additional Context:

The observed behavior can lead to potential issues and confusion, especially when there's a reliance on accurate thread ID values for debugging purposes.

Start with the Debug Adapter Protocol Stopped event specification and compare its threadId wording with the provided C++ reproduction. Trace the MIEngine handling of GDB -exec run, *stopped, and thread-info responses in the MI log, especially the distinction between thread ID 1 and LWP 18888. Done means the stopped event's threadId is consistent with the intended DAP semantics and the behavior is covered by an appropriate test.