Martin,
I hadn't really checked out debug "watches" in my multi-threaded app. Now I have and I discovered that local variables in a function, though they show the correct values when "moused over" (possibly important clue - I will look for where that's done), a watch item existing in the new thread's code, once in the new thread, reveals irrelevant data, apparently from another thread or frame. Watches displayed under a single threaded app work as expected. (Also, FWIW, watches work fine in gdb for multi or single-threaded apps).
Also, FWIW, the "arrowed" current thread in the debug/threads window, starts at threadID #1 before I initiate a new thread (proven by breakpoint at start of program). After a new thread starts up and a breakpoint in that thread #12 successfully stops, the threads window still shows thread ID #1 "selected" (arrow) even though I can also see that the code is breakpointed in threadid #12. Accordingly the local "str: string" variable which I set in the same thread #12 just before my second breakpoint displays incorrectly.
So, copying your approach with what you did in fixing the step issue, I modified the TLldbInstructionWatchSet.Create in LldbInstructions.pas -- see {kca}:
constructor TLldbInstructionWatchSet.Create(AWatch: String;
AKind: TDBGWatchPointKind
; {kca} AThread: Integer = -1; AFrame: Integer = -1);
begin
case AKind of
wpkWrite: inherited Create(Format('watchpoint set variable -w write %s', [AWatch]), {kca}AThread, AFrame);
wpkRead: inherited Create(Format('watchpoint set variable -w read %s', [AWatch]),{kca}AThread, AFrame);
wpkReadWrite: inherited Create(Format('watchpoint set variable -w read_write %s', [AWatch]),{kca}AThread, AFrame);
end;
end;
And in LldbDebugger.pas, I modified TLLdbBreakpoint.SetBreakPoint adding this under bpkData:
bpkData: begin
if not Enabled then // do not set, if not enabled
exit;
// TODO: scope
// TODO: apply , Expression, not Enabled
Instr := TLldbInstructionWatchSet.Create(WatchData, WatchKind,
{kca} TLldbDebugger(Debugger).FCurrentThreadId, TLldbDebugger(Debugger).FCurrentStackFrame);
if Expression <> '' then
FNeededChanges := FNeededChanges + [ciCondition];
end;
Actually, initially I tried just adding the threadid parameter, but since that didn't work, I added the additional stackframe parameter. Unfortunately, this didn't solve the problem -- but then I'm pretty much winging it :-)
Any ideas?