[lldb-dev] Cannot use system debugserver for testing

Mon Jul 22 07:14:28 PDT 2019

I am still struggling with this issue. Now I decided to work with the
codesigned version of the debugserver, becasue I had an error when I tried
to use the system debugserver.
So I've run scripts/macos-setup-codesign.sh
After a reboot and fresh build (I have removed the CMakeCache.txt and the
whole build dir) I have the debugserver signed:
```
$ codesign -dvvvv ~/llvm2/build/release_assert/bin/debugserver
Executable=/Users/egbomrt/llvm2/build/release_assert/bin/debugserver
Identifier=com.apple.debugserver
Format=Mach-O thin (x86_64)
CodeDirectory v=20100 size=38534 flags=0x0(none) hashes=1197+5
location=embedded
VersionPlatform=1
VersionMin=658944
VersionSDK=658944
Hash type=sha256 size=32
CandidateCDHash sha256=7b475cfa7127c84281ceb206093d13dd464dad74
Hash choices=sha256
Page size=4096
CDHash=7b475cfa7127c84281ceb206093d13dd464dad74
Signature size=1611
Authority=lldb_codesign
Signed Time=2019. Jul 22. 15:26:29
Info.plist entries=6
TeamIdentifier=not set
Sealed Resources=none
Internal requirements count=1 size=100
$
```

So far so good.
But then when I try to use lldb I have permission problems:
```
egbomrt at msmarple ~/llvm2/build/release_assert $ ./bin/lldb /bin/ls
(lldb) target create "/bin/ls"
Current executable set to '/bin/ls' (x86_64).
(lldb) r
*error: process exited with status -1 (Error 1)*
(lldb) ^D
egbomrt at msmarple ~/llvm2/build/release_assert $
```

However, as root I can use lldb:
```
egbomrt at msmarple ~/llvm2/build/release_assert $ sudo ./bin/lldb /bin/ls
(lldb) target create "/bin/ls"
Current executable set to '/bin/ls' (x86_64).
(lldb) r
Process 28052 launched: '/bin/ls' (x86_64)
.ninja_deps                     compile_commands.json
.ninja_log                      docs
CMakeCache.txt                  examples
CMakeDoxyfile.in                include
...
Process 28052 exited with status = 0 (0x00000000)
(lldb) ^D
egbomrt at msmarple ~/llvm2/build/release_assert $
```

Is it possible to codesign in a way that a regular user can run the built
debugserver? Or what else could be the reason behind this permission
problem?

Thanks,
Gabor

On Fri, Jul 19, 2019 at 11:47 PM Stefan Gränitz <stefan.graenitz at gmail.com>
wrote:

> Hi Gábor, I am sorry this caused an issue for you. Good that apparently
> it's resolved now.
>
> Did you reconfigure an existing build-tree? Your observations would make
> sense in this context, because the change affects CMake cached variables.
> This is unfortunate, but can not always be avoided. If this happens again
> (or to anyone else), a clean build seems to be a good first step.
>
> Best,
> Stefan
>
> On 19/07/2019 19:36, Gábor Márton wrote:
>
> Actually, it is embarrassing (perhaps for macOS and not for me) that after
> a reboot the problem is gone.
> Perhaps after "sudo /usr/sbin/DevToolsSecurity --enable" a reboot is
> required, but could not find anything official about that.
>
> On Fri, Jul 19, 2019 at 7:20 PM Gábor Márton <martongabesz at gmail.com>
> wrote:
>
>> This might not be related to the debugserver, I just realized that I get
>> "error: process exited with status -1 (Error 1)"
>> even with the simplest main.c.
>> This may be some kind of security issue on mac OS...
>> Though I've checked and I have SIP disabled and I have executed "sudo
>> /usr/sbin/DevToolsSecurity --enable".
>>
>> On Fri, Jul 19, 2019 at 4:46 PM Gábor Márton <martongabesz at gmail.com>
>> wrote:
>>
>>> Hi Stefan,
>>>
>>> Since the commit
>>> "[CMake] Always build debugserver on Darwin and allow tests to use the
>>> system's one"
>>> I cannot use the system debugserver for testing.
>>> I receive the following error message from lldb when I execute "ninja
>>> check-lldb":
>>> ```
>>> runCmd: run
>>> runCmd failed!
>>> error: process exited with status -1 (Error 1)
>>> ```
>>>
>>> I do set up "-DLLDB_USE_SYSTEM_DEBUGSERVER=ON" with cmake so I see
>>> ```
>>> -- LLDB tests use out-of-tree debugserver:
>>> /Library/Developer/CommandLineTools/Library/PrivateFrameworks/LLDB.framework/Resources/debugserver
>>> ```
>>>
>>> Also, I have inspected the following test output
>>> ```
>>> Command invoked: /usr/bin/python
>>> /Users/egbomrt/llvm2/git/llvm/tools/lldb/test/dotest.py -q --arch=x86_64 -s
>>> /Users/egbomrt/llvm2/build/release_assert/lldb-test-traces --build-dir
>>> /Users/egbomrt/llvm2/build/release_assert/lldb-test-build.noindex -S nm -u
>>> CXXFLAGS -u CFLAGS --executable
>>> /Users/egbomrt/llvm2/build/release_assert/./bin/lldb --dsymutil
>>> /Users/egbomrt/llvm2/build/release_assert/./bin/dsymutil --filecheck
>>> /Users/egbomrt/llvm2/build/release_assert/./bin/FileCheck -C
>>> /Users/egbomrt/llvm2/build/release_assert/bin/clang --codesign-identity -
>>> --out-of-tree-debugserver --arch x86_64 -t --env TERM=vt100 -p
>>> TestCModules.py --results-port 49931 -S nm --inferior -p TestCModules.py
>>> /Users/egbomrt/llvm2/git/llvm/tools/lldb/packages/Python/lldbsuite/test/lang/c/modules
>>> --event-add-entries worker_index=0:int
>>>   1 out of 736 test suites processed - TestCModules.py
>>> ```
>>> so it seems like the argument for --out-of-tree-debugserver is missing...
>>>
>>> Could you please advise?
>>>
>>> Thank you,
>>> Gabor
>>>
>> -- https://flowcrypt.com/pub/stefan.graenitz@gmail.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20190722/9da3421e/attachment.html>