Re: [lldb-dev] lldb test suite on macOS 10.13 (High Sierra)

2017-11-16 Thread Pavel Labath via lldb-dev
Right, after learning way more than I ever wanted to know about xcrun,
I think I see the issue. When running with empty SDKROOT variable,
xcrun sets SDKROOT to "/" when running clang:
$ SDKROOT= xcrun --no-cache --log --verbose clang
/Users/lldb_build/lldbSlave/buildDir/llvm/tools/lldb/packages/Python/lldbsuite/test/crashinfo.c
-o 
/Users/lldb_build/lldbSlave/buildDir/llvm/tools/lldb/packages/Python/lldbsuite/test/crashinfo.so
-framework Python -Xlinker -dylib -v
xcrun: note: PATH = '/usr/bin:/bin'
xcrun: note: SDKROOT = '/'
 ^ WRONG. there are no
python headers there

.

env SDKROOT=/ 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
/Users/lldb_build/lldbSlave/buildDir/llvm/tools/lldb/packages/Python/lldbsuite/test/crashinfo.c
-o 
/Users/lldb_build/lldbSlave/buildDir/llvm/tools/lldb/packages/Python/lldbsuite/test/crashinfo.so
-framework Python -Xlinker -dylib -v

...

#include "..." search starts here:
#include <...> search starts here:
 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/include
 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
  clang gets the include path wrong

End of search list.
/Users/lldb_build/lldbSlave/buildDir/llvm/tools/lldb/packages/Python/lldbsuite/test/crashinfo.c:15:10:
fatal error: 'Python/Python.h' file not found
#include 
 ^
1 error generated.
^ and errors out



On the other hand, if I invoke xcrun with SDKROOT=macosx, everything
works just fine:

$ SDKROOT=macosx xcrun --no-cache --log --verbose clang
/Users/lldb_build/lldbSlave/buildDir/llvm/tools/lldb/packages/Python/lldbsuite/test/crashinfo.c
-o 
/Users/lldb_build/lldbSlave/buildDir/llvm/tools/lldb/packages/Python/lldbsuite/test/crashinfo.so
-framework Python -Xlinker -dylib -v
xcrun: note: looking up SDK with
'/Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild -sdk
macosx -version Path'
xcrun: note: PATH = '/usr/bin:/bin'
xcrun: note: SDKROOT = 'macosx'
xcrun: note: TOOLCHAINS = ''
xcrun: note: DEVELOPER_DIR = '/Applications/Xcode.app/Contents/Developer'
xcrun: note: XCODE_DEVELOPER_USR_PATH = ''
xcrun: note: xcrun_db =
'/var/folders/bt/tws6gynx0ws1cc4ss53_pvqmgq/T/xcrun_db'
xcrun: note: lookup resolved to:
'/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk'
xcrun: note: PATH = '/usr/bin:/bin'
xcrun: note: SDKROOT =
'/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk'
^^ correct. a valid SDK is located there

...

env 
SDKROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
/Users/lldb_build/lldbSlave/buildDir/llvm/tools/lldb/packages/Python/lldbsuite/test/crashinfo.c
-o 
/Users/lldb_build/lldbSlave/buildDir/llvm/tools/lldb/packages/Python/lldbsuite/test/crashinfo.so
-framework Python -Xlinker -dylib -v

...

#include "..." search starts here:
#include <...> search starts here:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/include
 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include
 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks
(framework directory)

  ^ include path is good and compilation succeeds


I've checked this on 10.12 and the xcrun behavior is same there (with
the difference that 10.12 does contain headers in
/System/Library/Frameworks.

It seems we could fix this by changing the invocation in  dotest to
explicitly request SDKROOT=macosx. As far, as I can tell, this would
only break if someone tried to run dotest with iOS as host, but I
don't think that's ever going to be supported(?)

What do you think?


On 15 November 2017 at 20:25, Jim Ingham  wrote:
> The build should be finding the version in the SDK within Xcode.  I do have 
> the CommandLineTools directory on my system, but it doesn’t have an SDK 
> directory in it.  I wonder if that is causing the problem?
>
> One thing to check, do:
>
> $ xcrun -find clang
>
> Does that find clang in the DeveloperTools directory?  If so try:
>
> sudo xcode-select —switch /Applications/Xcode.app
>
> Then everything should point to the toolchain & SDK’s in Xcode.  If that 
> doesn’t help you might try moving the DeveloperTools aside and see if things 
> work then.  Xcode should not need that to work.
>
> Jim
>
>
>> On Nov 15, 2017, at 10:33 AM, Pavel Labath  wrote:
>>
>> Thanks

[lldb-dev] negative in stop reason

2017-11-16 Thread Jian Liu/Gmail via lldb-dev
Dear all,

I have just debug KLEE with lldb. A breakpoint was set on the function
"executeAllocUnbounded". After the breakpoint was hiited, I used "continue"
to let the program to go on. However, it did not work. The respose from
lldb is following:

(lldb)
Process 10254 stopped
* thread #1, name = 'klee', stop reason = breakpoint 3.1 -1364.1
frame #0:
klee`klee::Executor::executeAllocUnbounded(this=0x01278800,
state=0x0132d710, size=4, target=0x0134ef00) at
Executor.cpp:3036

NOTE that, there is a negative number "-1364.1" showed in stop reason. When
I hit "continue" again, the number was change to "-1366.1", by mius -2

I want to know what is the mean of "-1364.1" here. How to let the program
to continue. Thanks.

---
Jian Liu
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev