kendalharland wrote: > > ``` > > S:\SourceCache\llvm-project\lldb\test\Shell\Driver\TestConvenienceVariables.test:6:8: > > error: CHECK: expected string not found in input > > CHECK: stop reason = breakpoint 1.1 > > ^ > > <stdin>:1:1: note: scanning from here > > (lldb) command source -s 0 > > 'S:/b/1/tools/lldb\test\Shell\lit-lldb-init-quiet' > > ^ > > <stdin>:13:14: note: possible intended match here > > * thread #1, stop reason = breakpoint 1.2 > > ^ > > ``` > > > > > > > > > > > > > > > > > > > > > > > > I think it's just that it expected 1.1 and got 1.2. I don't know what the > > bit after the point means, is it the location? So this did `breakpoint set > > -f hello.cpp -p Hello` and somehow `1 location added to breakpoint 1` but > > yet it hit a second location? > > Which doesn't make sense so maybe the `.2` means something else. > > That's exactly what it means. The breakpoint gets one location when its set > (the process is not running yet): > > > ``` > > 9: Breakpoint 1: where = target.out`main + 21 at hello.cpp:4, address > > = 0x0000000140001015 > > ``` > > and then another when when it runs: > > > ``` > > 11: 1 location added to breakpoint 1 > > ``` > > Although this test doesn't really care about the number of breakpoint > locations (so we could just delete the `.1` part), I am wondering if this > isn't a symptom of a larger problem. Can you try running these commands > manually and print more information about the state of the process (for > starters, the output of `image list` and `breakpoint list -v` both before and > after `run` command). > > Also, the duplicate location reminds me of some similar situations where we > (used to?) fail to correctly unique modules in presence of symlinks and > stuff. What can you tell us about the path > (`S:\b\1\tools\lldb\test\Shell\Driver\Output\TestConvenienceVariables.test.tmp\target.out`) > where this binary is running from? Does it contain any symlinks (junctions), > funky drive mappins or anything else that would make the file appear to have > multiple paths?
After https://github.com/llvm/llvm-project/pull/100477 I learned that my CMake configuration is largely to blame for most of the failures I was observing. TestConvenienceVariables.test is now passing for me and I am investigating why TestSingleQuote.test is still failing. I will fold this change into https://github.com/llvm/llvm-project/pull/100476 and work with @dzhidzhoev to figure out why my build results do match those in his Windows Native CI and those in lldb-aarch-windows first. https://github.com/llvm/llvm-project/pull/100473 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
