[Lldb-commits] [lldb] [lldb][test][win][x86_64] XFAIL already failing Shell/Driver tests (PR #100473)

[Kendal Harland via lldb-commits]

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