[lldb-dev] Cannot use system debugserver for testing
Gábor Márton via lldb-dev
lldb-dev at lists.llvm.org
Mon Jul 22 07:59:21 PDT 2019
Yes, here it is.
egbomrt at msmarple ~/llvm2/build/release_assert $ ./bin/lldb ~/a.out
(lldb) target create "/Users/egbomrt/a.out"
Current executable set to '/Users/egbomrt/a.out' (x86_64).
(lldb) log enable lldb default
(lldb) r
Processing command: r
HandleCommand, cmd_obj : 'process launch'
HandleCommand, (revised) command_string: 'process launch -X true --'
HandleCommand, wants_raw_input:'False'
HandleCommand, command line after removing command name(s): '-X true --'
Target::Launch() called for /Users/egbomrt/a.out
Target::Launch the process instance doesn't currently exist.
have platform=true, platform_sp->IsHost()=true, default_to_use_pty=true
at least one of stdin/stdout/stderr was not set, evaluating default
handling
target stdin='(empty)', target stdout='(empty)', stderr='(empty)'
Generating a pty to use for stdin/out/err
Target::Launch asking the platform to debug the process
Host::StartMonitoringChildProcess (callback, pid=94887, monitor_signals=0)
source = 0x7f9bb923ec10
::waitpid (pid = 94887, &status, 0) => pid = 94887, status = 0x00000000
(EXITED), signal = 0, exit_status = 0
Host::StartMonitoringChildProcess (callback, pid=94888, monitor_signals=0)
source = 0x7f9bb9218180
Went to stop the private state thread, but it was already invalid.
Process::SetPublicState (state = attaching, restarted = 0)
Host::StartMonitoringChildProcess (callback, pid=94889, monitor_signals=0)
source = 0x7f9bb9243bd0
thread created
Process::AttachCompletionHandler::AttachCompletionHandler
process=0x7f9bb8803c18, exec_count=0
Process::ControlPrivateStateThread (signal = 4)
Sending control event of type: 4.
thread created
Process::RunPrivateStateThread (arg = 0x7f9bb8803c18, pid = 94888) thread
starting...
timeout = <infinite>, event_sp)...
Process::RunPrivateStateThread (arg = 0x7f9bb8803c18, pid = 94888) got a
control event: 4
timeout = <infinite>, event_sp)...
timeout = <infinite>
timeout = <infinite>, event_sp)...
thread created
Process::SetExitStatus (status=-1 (0xffffffff), description="Error 1")
Process::SetPrivateState (exited)
Process::SetPrivateState (exited) stop_id = 1
Process::AttachCompletionHandler::PerformAction called with state exited
(10)
Ran next event action, result was 2.
Process::ShouldBroadcastEvent (0x7f9bb92423b0) => new state: exited, last
broadcast state: exited - YES
Process::HandlePrivateEvent (pid = 94888) broadcasting new state exited
(old state attaching) to hijacked
Process::RunPrivateStateThread (arg = 0x7f9bb8803c18, pid = 94888) about
to exit with internal state exited...
Process::RunPrivateStateThread (arg = 0x7f9bb8803c18, pid = 94888) thread
exiting...
Process::SetPublicState (state = exited, restarted = 0)
timeout = <infinite>, event_sp) => exited
HandleCommand, command did not succeed
error: process exited with status -1 (Error 1)
(lldb) ::waitpid (pid = 94889, &status, 0) => pid = 94889, status =
0x00000000 (EXITED), signal = 0, exit_status = 0
(lldb)
On Mon, Jul 22, 2019 at 4:44 PM Stefan Gränitz <stefan.graenitz at gmail.com>
wrote:
> Interesting. Is there any extra info dumped to the log (e.g. `log enable
> lldb default`)
>
> On 22/07/2019 16:34, Gábor Márton wrote:
>
> Well, SIP is turned off and I experience the same with a binary I just
> built:
> ```
> egbomrt at msmarple ~/llvm2/build/release_assert $ csrutil status
> System Integrity Protection status: disabled.
> egbomrt at msmarple ~/llvm2/build/release_assert $ ./bin/lldb ~/a.out
> (lldb) target create "/Users/egbomrt/a.out"
> Current executable set to '/Users/egbomrt/a.out' (x86_64).
> (lldb) r
> error: process exited with status -1 (Error 1)
> (lldb) ^D
> egbomrt at msmarple ~/llvm2/build/release_assert $ ls -la ~/a.out
> -rwxr-xr-x 1 egbomrt admin 8736 Júl 22 16:16 /Users/egbomrt/a.out
> egbomrt at msmarple ~/llvm2/build/release_assert $
> ```
>
> On Mon, Jul 22, 2019 at 4:29 PM Stefan Gränitz <stefan.graenitz at gmail.com>
> wrote:
>
>> 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)*
>>
>> I don't think this is related to debugserver codesigning. If you really
>> need to debug system binaries, you may need to disable SIP.
>>
>> On 22/07/2019 16:14, Gábor Márton wrote:
>>
>> 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
>>>
>>> -- https://flowcrypt.com/pub/stefan.graenitz@gmail.com
>>
>> -- 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/26e39110/attachment-0001.html>
More information about the lldb-dev
mailing list