Re: [lldb-dev] [cfe-dev] [Release-testers] [9.0.0 Release] The release branch is open; trunk is now 10.0.0

[Anton Korobeynikov via lldb-dev]

> > When the branch is in good enough shape, hopefully by tomorrow, the
> > first release candidate (RC1) will be tagged and testing can begin.
> > The release schedule can be found under "Upcoming Releases" to the
> > right at https://llvm.org
> >
>
> Could you please do the necessary magic for 'release_90' branches to
> appear on llvm-mirror/* repos?
Should be there. At lest on official mirrors


-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] 8.0.1-final has been tagged

[Dimitry Andric via lldb-dev]

On 20 Jul 2019, at 05:21, Tom Stellard via Release-testers 
 wrote:
> The 8.0.1 final release has been tagged.  Testers please upload the final
> binaries.

As with 8.0.1 rc4, I had to disable compiler-rt for this test run, as most of 
the sanitizers are totally broken. This is tracked in PR40761.

Main test results on amd64-freebsd11:

Expected Passes: 53258 (rc4: 53262)
Passes With Retry  : 0 (rc4: 1)
Expected Failures  :   213 (rc4:   213)
Unsupported Tests  :  1718 (rc4:  1718)
Unresolved Tests   : 9 (rc4: 8)
Unexpected Passes  : 3 (rc4: 3)
Unexpected Failures:66 (rc4:62)

Main test results on i386-freebsd11:

Expected Passes: 53113 (rc4: 53114)
Passes With Retry  : 0 (rc4: 1)
Expected Failures  :   229 (rc4:   229)
Unsupported Tests  :  1540 (rc4:  1540)
Unresolved Tests   : 8 (rc4: 8)
Unexpected Passes  : 5 (rc4: 5)
Unexpected Failures:   177 (rc4:   175)

Uploaded:

SHA256 (clang+llvm-8.0.1-amd64-unknown-freebsd11.tar.xz) = 
4ae625169fa0ae56cf534cddc6f8eda76123f89adac0de439d0e47885fccc813
SHA256 (clang+llvm-8.0.1-i386-unknown-freebsd11.tar.xz) = 
f0ab06cce95f9339af3e27e728913414a7b775a5bdb6c90e2a4f67f8cf2a917e

-Dimitry



signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Cannot use system debugserver for testing

[Gábor Márton via lldb-dev]

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 -d ~/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@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@msmarple ~/llvm2/build/release_assert $
```

However, as root I can use lldb:
```
egbomrt@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.ininclude
...
Process 28052 exited with status = 0 (0x)
(lldb) ^D
egbomrt@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 
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 
> 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 
>> 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...
>>>
>>> C

Re: [lldb-dev] Cannot use system debugserver for testing

[Stefan Gränitz via lldb-dev]

> egbomrt@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 -d ~/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@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@msmarple ~/llvm2/build/release_assert $
> ```
>
> However, as root I can use lldb:
> ```
> egbomrt@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 (0x)
> (lldb) ^D
> egbomrt@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
> mailto:stefan.graen...@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
>> mailto:martongab...@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
>> mailto:martongab...@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: 

Re: [lldb-dev] Cannot use system debugserver for testing

[Gábor Márton via lldb-dev]

Well, SIP is turned off and I experience the same with a binary I just
built:
```
egbomrt@msmarple ~/llvm2/build/release_assert $ csrutil status
System Integrity Protection status: disabled.
egbomrt@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@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@msmarple ~/llvm2/build/release_assert $
```

On Mon, Jul 22, 2019 at 4:29 PM Stefan Gränitz 
wrote:

> egbomrt@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 -d ~/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@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@msmarple ~/llvm2/build/release_assert $
> ```
>
> However, as root I can use lldb:
> ```
> egbomrt@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.ininclude
> ...
> Process 28052 exited with status = 0 (0x)
> (lldb) ^D
> egbomrt@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 
> 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 
>> 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 
>>> 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
 

Re: [lldb-dev] Cannot use system debugserver for testing

[Stefan Gränitz via lldb-dev]

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@msmarple ~/llvm2/build/release_assert $ csrutil status
> System Integrity Protection status: disabled.
> egbomrt@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@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@msmarple ~/llvm2/build/release_assert $
> ```
>
> On Mon, Jul 22, 2019 at 4:29 PM Stefan Gränitz
> mailto:stefan.graen...@gmail.com>> wrote:
>
>> egbomrt@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 -d ~/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@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@msmarple ~/llvm2/build/release_assert $
>> ```
>>
>> However, as root I can use lldb:
>> ```
>> egbomrt@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 (0x)
>> (lldb) ^D
>> egbomrt@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
>> mailto:stefan.graen...@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
>>> mailto:martongab...@gmail.com>> wrote:
>>>
>>> This might not be related to the debugserver, I just
>>> realized that I ge

Re: [lldb-dev] Cannot use system debugserver for testing

[Gábor Márton via lldb-dev]

Yes, here it is.

egbomrt@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 = 0x
(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 = , event_sp)...
 Process::RunPrivateStateThread (arg = 0x7f9bb8803c18, pid = 94888) got a
control event: 4
 timeout = , event_sp)...
 timeout = 
 timeout = , event_sp)...
 thread created
 Process::SetExitStatus (status=-1 (0x), 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 = , 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 =
0x (EXITED), signal = 0, exit_status = 0
(lldb)

On Mon, Jul 22, 2019 at 4:44 PM Stefan Gränitz 
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@msmarple ~/llvm2/build/release_assert $ csrutil status
> System Integrity Protection status: disabled.
> egbomrt@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@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@msmarple ~/llvm2/build/release_assert $
> ```
>
> On Mon, Jul 22, 2019 at 4:29 PM Stefan Gränitz 
> wrote:
>
>> egbomrt@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 -d ~/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
>> Candidate

Re: [lldb-dev] Cannot use system debugserver for testing

[Gábor Márton via lldb-dev]

Some more info: I've stopped lldb (with the system lldb) when
" Process::SetExitStatus (status=-1 (0x), description="Error 1")"
is logged and gathered some more information.
Is it possible that some packet types are not implemented?

  * frame #0: 0x7fff599452c6 libsystem_kernel.dylib`__pthread_kill + 10
frame #1: 0x7fff59a00bf1 libsystem_pthread.dylib`pthread_kill + 284
frame #2: 0x7fff598af6a6 libsystem_c.dylib`abort + 127
frame #3: 0x7fff5987820d libsystem_c.dylib`__assert_rtn + 324
frame #4: 0x00010b393539
liblldb.10.0.99svn.dylib`lldb_private::Process::SetExitStatus(this=0x7fcfaa470218,
status=-1, cstr="Error 1") at Process.cpp:1149:3
frame #5: 0x00010bbd1792
liblldb.10.0.99svn.dylib`lldb_private::process_gdb_remote::ProcessGDBRemote::AsyncThread(arg=0x7fcfaa470218)
at ProcessGDBRemote.cpp:3877:28
frame #6: 0x00010b08f87b
liblldb.10.0.99svn.dylib`lldb_private::HostNativeThreadBase::ThreadCreateTrampoline(arg=0x7fcfab218740)
at HostNativeThreadBase.cpp:69:10
frame #7: 0x000112be72fd
liblldb.10.0.99svn.dylib`lldb_private::HostThreadMacOSX::ThreadCreateTrampoline(arg=0x7fcfab218740)
at HostThreadMacOSX.mm:68:10
frame #8: 0x7fff599fe2eb libsystem_pthread.dylib`_pthread_body + 126
frame #9: 0x7fff59a01249 libsystem_pthread.dylib`_pthread_start + 66
frame #10: 0x7fff599fd40d libsystem_pthread.dylib`thread_start + 13
(lldb) frame select 5
frame #5: 0x00010bbd1792
liblldb.10.0.99svn.dylib`lldb_private::process_gdb_remote::ProcessGDBRemote::AsyncThread(arg=0x7fcfaa470218)
at ProcessGDBRemote.cpp:3877:28
   3874  "System Integrity
Protection");
   3875 } else if (::strstr(continue_cstr, "vAttach") !=
nullptr &&
   3876response.GetStatus().Fail()) {
-> 3877   process->SetExitStatus(-1,
response.GetStatus().AsCString());
   3878 } else {
   3879   process->SetExitStatus(-1, "lost connection");
   3880 }
(lldb) p response.GetError()
(uint8_t) $0 = '\x01'
(lldb) p response.GetServerPacketType()
(StringExtractorGDBRemote::ServerPacketType) $1 =
*eServerPacketType_unimplemented*
(lldb) p response.GetResponseType()
(StringExtractorGDBRemote::ResponseType) $2 = eError
(lldb) p response.IsUnsupportedResponse()
(bool) $3 = false
(lldb) p response.GetStatus()
(lldb_private::Status) $4 = (m_code = 1, m_type = eErrorTypeGeneric,
m_string = "Error 1")


Thanks,
Gabor

On Mon, Jul 22, 2019 at 4:59 PM Gábor Márton  wrote:

> Yes, here it is.
>
> egbomrt@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 = 0x
> (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 = , event_sp)...
>  Process::RunPrivateStateThread (arg = 0x7f9bb8803c18, pid = 94888) got a
> control event: 4
>  timeout = , event_sp)...
>  timeout = 
>  timeout = , event_sp)...
>  thread created
>  Process::SetExitStatus (status=-1 (0x), 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: ex

Re: [lldb-dev] Cannot use system debugserver for testing

[Frédéric Riss via lldb-dev]

I think the system logs (in Console.app) would tell us more. Search for 
debugserver and you should find attach failures. Then remove the filter and 
look at what happens right before that. There should be a log from taskgated or 
authd that is a little more explicit about what’s failing.

Fred 

> On Jul 22, 2019, at 8:55 AM, Gábor Márton via lldb-dev 
>  wrote:
> 
> Some more info: I've stopped lldb (with the system lldb) when " 
> Process::SetExitStatus (status=-1 (0x), description="Error 1")" is 
> logged and gathered some more information.
> Is it possible that some packet types are not implemented?
> 
>   * frame #0: 0x7fff599452c6 libsystem_kernel.dylib`__pthread_kill + 10
> frame #1: 0x7fff59a00bf1 libsystem_pthread.dylib`pthread_kill + 284
> frame #2: 0x7fff598af6a6 libsystem_c.dylib`abort + 127
> frame #3: 0x7fff5987820d libsystem_c.dylib`__assert_rtn + 324
> frame #4: 0x00010b393539 
> liblldb.10.0.99svn.dylib`lldb_private::Process::SetExitStatus(this=0x7fcfaa470218,
>  status=-1, cstr="Error 1") at Process.cpp:1149:3
> frame #5: 0x00010bbd1792 
> liblldb.10.0.99svn.dylib`lldb_private::process_gdb_remote::ProcessGDBRemote::AsyncThread(arg=0x7fcfaa470218)
>  at ProcessGDBRemote.cpp:3877:28
> frame #6: 0x00010b08f87b 
> liblldb.10.0.99svn.dylib`lldb_private::HostNativeThreadBase::ThreadCreateTrampoline(arg=0x7fcfab218740)
>  at HostNativeThreadBase.cpp:69:10
> frame #7: 0x000112be72fd 
> liblldb.10.0.99svn.dylib`lldb_private::HostThreadMacOSX::ThreadCreateTrampoline(arg=0x7fcfab218740)
>  at HostThreadMacOSX.mm:68:10
> frame #8: 0x7fff599fe2eb libsystem_pthread.dylib`_pthread_body + 126
> frame #9: 0x7fff59a01249 libsystem_pthread.dylib`_pthread_start + 66
> frame #10: 0x7fff599fd40d libsystem_pthread.dylib`thread_start + 13
> (lldb) frame select 5
> frame #5: 0x00010bbd1792 
> liblldb.10.0.99svn.dylib`lldb_private::process_gdb_remote::ProcessGDBRemote::AsyncThread(arg=0x7fcfaa470218)
>  at ProcessGDBRemote.cpp:3877:28
>3874  "System Integrity 
> Protection");
>3875 } else if (::strstr(continue_cstr, "vAttach") != 
> nullptr &&
>3876response.GetStatus().Fail()) {
> -> 3877   process->SetExitStatus(-1, 
> response.GetStatus().AsCString());
>3878 } else {
>3879   process->SetExitStatus(-1, "lost connection");
>3880 }
> (lldb) p response.GetError()
> (uint8_t) $0 = '\x01'
> (lldb) p response.GetServerPacketType()
> (StringExtractorGDBRemote::ServerPacketType) $1 = 
> eServerPacketType_unimplemented
> (lldb) p response.GetResponseType()
> (StringExtractorGDBRemote::ResponseType) $2 = eError
> (lldb) p response.IsUnsupportedResponse()
> (bool) $3 = false
> (lldb) p response.GetStatus()
> (lldb_private::Status) $4 = (m_code = 1, m_type = eErrorTypeGeneric, m_string 
> = "Error 1")
> 
> 
> Thanks,
> Gabor
> 
> On Mon, Jul 22, 2019 at 4:59 PM Gábor Márton  > wrote:
> Yes, here it is.
> 
> egbomrt@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 = 0x 
> (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 = , event_sp)

[lldb-dev] ASTImporter Tutorial/TechTalk and RoundTable

[Gábor Márton via lldb-dev]

Hi,

I am planning to submit a talk about ASTImporter to the upcoming Dev
Meeting at October 22-23, 2019.
I'd like to talk about
- the API,
- how it is used in CTU analysis and in LLDB,
- internal subtleties and difficulties (Error handling, ExternalASTSource,
...)
The goal would be to attract more developers to use and improve ASTImporter
related code, so perhaps this will be a tutorial.

Independently from the talk, I'd like to have a round table discussion if
there is enough interest.
Some topics could cover future development ideas and existing problems we
have.
Please get back to me if you are interested and think about the topics you
have in mind, also don't forget to buy your ticket to the DevMeeting.

Thanks,
Gabor
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Cannot use system debugserver for testing

[Gábor Márton via lldb-dev]

Ok, I've done that, here are the logs which happen before the first
debugserver error:

error 18:33:20.236506 +0200 taskgated cannot open file at line 42270 of
[95fbac39ba]
error 18:33:20.236526 +0200 taskgated os_unix.c:42270: (2)
open(/var/db/DetachedSignatures) - No such file or directory
default 18:33:20.236586 +0200 taskgated MacOS error: -67062
error 18:33:20.246771 +0200 taskgated cannot open file at line 42270 of
[95fbac39ba]
error 18:33:20.246787 +0200 taskgated os_unix.c:42270: (2)
open(/var/db/DetachedSignatures) - No such file or directory
default 18:33:20.246841 +0200 taskgated MacOS error: -67062
default 18:33:20.260319 +0200 debugserver debugserver will use os_log for
internal logging.
default 18:33:20.260491 +0200 debugserver debugserver-@(#)PROGRAM:LLDB
 PROJECT:lldb-360.99.0
 for x86_64.
default 18:33:20.260615 +0200 debugserver Got a connection, waiting for
process information for launching or attaching.
default 18:33:20.264541 +0200 trustd cert[0]: AnchorTrusted =(leaf)[force]>
0
default 18:33:20.272256 +0200 trustd cert[2]: AnchorTrusted =(leaf)[force]>
0
default 18:33:20.276567 +0200 trustd cert[2]: AnchorTrusted =(leaf)[force]>
0
default 18:33:20.278680 +0200 authd UNIX error exception: 3
error 18:33:20.279462 +0200 authd process: PID 27648 failed to create code
ref 13
error 18:33:20.280017 +0200 authd Fatal: interaction not allowed (session
has no ui access) (engine 3727)
default 18:33:20.280031 +0200 authd Failed to authorize right
'system.privilege.taskport' by client '/usr/libexec/taskgated' [254] for
authorization created by '/usr/libexec/taskgated' [27648] (3,1) (-60007)
(engine 3727)
error 18:33:20.280092 +0200 authd copy_rights: authorization failed
error 18:33:20.280442 +0200 debugserver error:
MachTask::TaskPortForProcessID task_for_pid failed: ::task_for_pid (
target_tport = 0x0103, pid = 27646, &task ) => err = 0x0005 ((os/kern)
failure)


On Mon, Jul 22, 2019 at 6:10 PM Frédéric Riss  wrote:

> I think the system logs (in Console.app) would tell us more. Search for
> debugserver and you should find attach failures. Then remove the filter and
> look at what happens right before that. There should be a log from
> taskgated or authd that is a little more explicit about what’s failing.
>
> Fred
>
> On Jul 22, 2019, at 8:55 AM, Gábor Márton via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Some more info: I've stopped lldb (with the system lldb) when
> " Process::SetExitStatus (status=-1 (0x), description="Error 1")"
> is logged and gathered some more information.
> Is it possible that some packet types are not implemented?
>
>   * frame #0: 0x7fff599452c6 libsystem_kernel.dylib`__pthread_kill + 10
> frame #1: 0x7fff59a00bf1 libsystem_pthread.dylib`pthread_kill + 284
> frame #2: 0x7fff598af6a6 libsystem_c.dylib`abort + 127
> frame #3: 0x7fff5987820d libsystem_c.dylib`__assert_rtn + 324
> frame #4: 0x00010b393539
> liblldb.10.0.99svn.dylib`lldb_private::Process::SetExitStatus(this=0x7fcfaa470218,
> status=-1, cstr="Error 1") at Process.cpp:1149:3
> frame #5: 0x00010bbd1792
> liblldb.10.0.99svn.dylib`lldb_private::process_gdb_remote::ProcessGDBRemote::AsyncThread(arg=0x7fcfaa470218)
> at ProcessGDBRemote.cpp:3877:28
> frame #6: 0x00010b08f87b
> liblldb.10.0.99svn.dylib`lldb_private::HostNativeThreadBase::ThreadCreateTrampoline(arg=0x7fcfab218740)
> at HostNativeThreadBase.cpp:69:10
> frame #7: 0x000112be72fd
> liblldb.10.0.99svn.dylib`lldb_private::HostThreadMacOSX::ThreadCreateTrampoline(arg=0x7fcfab218740)
> at HostThreadMacOSX.mm:68:10
> frame #8: 0x7fff599fe2eb libsystem_pthread.dylib`_pthread_body +
> 126
> frame #9: 0x7fff59a01249 libsystem_pthread.dylib`_pthread_start +
> 66
> frame #10: 0x7fff599fd40d libsystem_pthread.dylib`thread_start + 13
> (lldb) frame select 5
> frame #5: 0x00010bbd1792
> liblldb.10.0.99svn.dylib`lldb_private::process_gdb_remote::ProcessGDBRemote::AsyncThread(arg=0x7fcfaa470218)
> at ProcessGDBRemote.cpp:3877:28
>3874  "System Integrity
> Protection");
>3875 } else if (::strstr(continue_cstr, "vAttach") !=
> nullptr &&
>3876response.GetStatus().Fail()) {
> -> 3877   process->SetExitStatus(-1,
> response.GetStatus().AsCString());
>3878 } else {
>3879   process->SetExitStatus(-1, "lost connection");
>3880 }
> (lldb) p response.GetError()
> (uint8_t) $0 = '\x01'
> (lldb) p response.GetServerPacketType()
> (StringExtractorGDBRemote::ServerPacketType) $1 =
> *eServerPacketType_unimplemented*
> (lldb) p response.GetResponseType()
> (StringExtractorGDBRemote::ResponseType) $2 = eError
> (lldb) p response.IsUnsupportedResponse()
> (bool) $3 = false
> (lldb) p response.GetStatus()
> (lldb_private::Status) $4 = (m_code = 1, m_type = eErrorTypeGeneric,
> m_stri

Re: [lldb-dev] Cannot use system debugserver for testing

[Gábor Márton via lldb-dev]

*error 18:33:20.280017 +0200 authd Fatal: interaction not allowed (session
has no ui access) (engine 3727)*
This gave me a hint, so I used VPN to have a gui and got a gui window
popped up to authenticate lldb. And then I could run lldb as a normal user.
Hurray!

BUT through ssh I still cannot run lldb that as a normal user.
I've seen you have
```
@@@ Setup @@@
Unlocking keychain /Users/buildslave/Library/Keychains/lldb.keychain-db ...
[1;32mOK [0m
+ echo @@
@@
```
at your build bot at greenlab.

So I tried "security -v unlock-keychain /Library/Keychains/System.keychain"
but that did not work, I believe because scripts/macos-setup-codesign.sh
did not ask for a password for the keychain (it asked for pw because of
sudo).
Is this the way to work if I don't have GUI (I must work via SSH, and this
ought to be part of a CI) ?
Should I recreate the keychain with a pw somehow?

Thanks


On Mon, Jul 22, 2019 at 6:47 PM Gábor Márton  wrote:

> Ok, I've done that, here are the logs which happen before the first
> debugserver error:
>
> error 18:33:20.236506 +0200 taskgated cannot open file at line 42270 of
> [95fbac39ba]
> error 18:33:20.236526 +0200 taskgated os_unix.c:42270: (2)
> open(/var/db/DetachedSignatures) - No such file or directory
> default 18:33:20.236586 +0200 taskgated MacOS error: -67062
> error 18:33:20.246771 +0200 taskgated cannot open file at line 42270 of
> [95fbac39ba]
> error 18:33:20.246787 +0200 taskgated os_unix.c:42270: (2)
> open(/var/db/DetachedSignatures) - No such file or directory
> default 18:33:20.246841 +0200 taskgated MacOS error: -67062
> default 18:33:20.260319 +0200 debugserver debugserver will use os_log for
> internal logging.
> default 18:33:20.260491 +0200 debugserver debugserver-@(#)PROGRAM:LLDB
>  PROJECT:lldb-360.99.0
>  for x86_64.
> default 18:33:20.260615 +0200 debugserver Got a connection, waiting for
> process information for launching or attaching.
> default 18:33:20.264541 +0200 trustd cert[0]: AnchorTrusted
> =(leaf)[force]> 0
> default 18:33:20.272256 +0200 trustd cert[2]: AnchorTrusted
> =(leaf)[force]> 0
> default 18:33:20.276567 +0200 trustd cert[2]: AnchorTrusted
> =(leaf)[force]> 0
> default 18:33:20.278680 +0200 authd UNIX error exception: 3
> error 18:33:20.279462 +0200 authd process: PID 27648 failed to create code
> ref 13
> error 18:33:20.280017 +0200 authd Fatal: interaction not allowed (session
> has no ui access) (engine 3727)
> default 18:33:20.280031 +0200 authd Failed to authorize right
> 'system.privilege.taskport' by client '/usr/libexec/taskgated' [254] for
> authorization created by '/usr/libexec/taskgated' [27648] (3,1) (-60007)
> (engine 3727)
> error 18:33:20.280092 +0200 authd copy_rights: authorization failed
> error 18:33:20.280442 +0200 debugserver error:
> MachTask::TaskPortForProcessID task_for_pid failed: ::task_for_pid (
> target_tport = 0x0103, pid = 27646, &task ) => err = 0x0005 ((os/kern)
> failure)
>
>
> On Mon, Jul 22, 2019 at 6:10 PM Frédéric Riss  wrote:
>
>> I think the system logs (in Console.app) would tell us more. Search for
>> debugserver and you should find attach failures. Then remove the filter and
>> look at what happens right before that. There should be a log from
>> taskgated or authd that is a little more explicit about what’s failing.
>>
>> Fred
>>
>> On Jul 22, 2019, at 8:55 AM, Gábor Márton via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>> Some more info: I've stopped lldb (with the system lldb) when
>> " Process::SetExitStatus (status=-1 (0x), description="Error 1")"
>> is logged and gathered some more information.
>> Is it possible that some packet types are not implemented?
>>
>>   * frame #0: 0x7fff599452c6 libsystem_kernel.dylib`__pthread_kill +
>> 10
>> frame #1: 0x7fff59a00bf1 libsystem_pthread.dylib`pthread_kill +
>> 284
>> frame #2: 0x7fff598af6a6 libsystem_c.dylib`abort + 127
>> frame #3: 0x7fff5987820d libsystem_c.dylib`__assert_rtn + 324
>> frame #4: 0x00010b393539
>> liblldb.10.0.99svn.dylib`lldb_private::Process::SetExitStatus(this=0x7fcfaa470218,
>> status=-1, cstr="Error 1") at Process.cpp:1149:3
>> frame #5: 0x00010bbd1792
>> liblldb.10.0.99svn.dylib`lldb_private::process_gdb_remote::ProcessGDBRemote::AsyncThread(arg=0x7fcfaa470218)
>> at ProcessGDBRemote.cpp:3877:28
>> frame #6: 0x00010b08f87b
>> liblldb.10.0.99svn.dylib`lldb_private::HostNativeThreadBase::ThreadCreateTrampoline(arg=0x7fcfab218740)
>> at HostNativeThreadBase.cpp:69:10
>> frame #7: 0x000112be72fd
>> liblldb.10.0.99svn.dylib`lldb_private::HostThreadMacOSX::ThreadCreateTrampoline(arg=0x7fcfab218740)
>> at HostThreadMacOSX.mm:68:10
>> frame #8: 0x7fff599fe2eb libsystem_pthread.dylib`_pthread_body +
>> 126
>> frame #9: 0x7fff59a01249 libsystem_pthread.dylib`_pthread_start +
>> 66
>> frame #10: 0x7fff599fd40d libsystem_pthread.dylib`thread_start +
>> 13
>> (lldb) frame select 5
>> frame #5: 0x00010

Re: [lldb-dev] queue-name parameter

[Jim Ingham via lldb-dev]

I already filed both of these issues with Apple.  If you want to file them too, 
feel free.  I'll dup them to the ones I filed but that way you will get 
notification when they get fixed.  These are also general lldb issues, so it 
would be good to file something with http://bugs.llvm.org.

Jim


> On Jul 19, 2019, at 3:20 AM, Fernando Bunn  wrote:
> 
> Jim,
> you're right, I was getting a false positive with -Q, sorry for the confusion.
> 
> So it seems I'm having 2 issues on Xcode, right?
> A - No rejection of illegal options (-Q)
> B - "-q" with the correct queue name is not working.
> 
> Here's what I'm doing for B:
> 
> 1 - (lldb) thread info
> thread #1: tid = 0xfc5f, 0x0001070418f4 
> ThreadTest`ViewController.viewDidLoad(self=0x7f940610d270) at 
> ViewController.swift:16:9, queue = 'com.apple.main-thread', stop reason = 
> breakpoint 1.1
> 
> 2 - (lldb) breakpoint set --file ViewController.swift --line 26 -q 
> com.apple.main-thread
> Breakpoint 2: where = ThreadTest`ThreadTest.ViewController.viewDidLoad() -> 
> () + 942 at ViewController.swift:26:15, address = 0x000107041c0e
> 
> 3 - (lldb) breakpoint list 2
> 2: file = 'ViewController.swift', line = 26, exact_match = 0, locations = 1, 
> resolved = 1, hit count = 0 Options: enabled queue name: 
> "com.apple.main-thread" 
>   2.1: where = ThreadTest`ThreadTest.ViewController.viewDidLoad() -> () + 942 
> at ViewController.swift:26:15, address = 0x000107041c0e, resolved, hit 
> count = 0 
> 
> On #1 I just make sure the queue name is correct, com.apple.main-thread, then 
> on #2 I set the breakpoint with "-q", and on #3 I make sure that the 
> parameter was set correctly, and I do see the enabled queue name: 
> "com.apple.main-thread" in there, but the breakpoint is never executed.
> 
> But if I set  breakpoint set --file ViewController.swift --line 26, without 
> -q, the breakpoint is executed normally. 
> And to check that the queue name is "com.apple.main-thread" when this 
> breakpoint is executed I did the following:
> 
> 1 - (lldb) breakpoint set --file ViewController.swift --line 26
> Breakpoint 3: where = ThreadTest`ThreadTest.ViewController.viewDidLoad() -> 
> () + 942 at ViewController.swift:26:15, address = 0x000104a01c0e
> 2 - (lldb) c
> Process 1242 resuming
> 3 - (lldb) thread info
> thread #1: tid = 0x11cd2, 0x000104a01c0e 
> ThreadTest`ViewController.viewDidLoad(self=0x7fcb15d09d50) at 
> ViewController.swift:26:15, queue = 'com.apple.main-thread', stop reason = 
> breakpoint 3.1
> 
> I can verify that on #3 the queue name is in fact com.apple.main-thread but 
> if I add -q com.apple.main-thread, it doesn't work.
> 
> At this point, I'm not sure what to do next, maybe file a radar with Apple?
> Thanks for your help, I really appreciate it :)
> 
> --
> Fernando
> 
> 
> 
> On Fri, Jul 19, 2019 at 1:27 AM Jim Ingham  wrote:
> Fernando, I don't see quite what you do.  For me, -Q never sets the queue.  
> Rather, the current Xcode version of lldb seems to have a bug where it 
> doesn't reject illegal options, so the -Q argument is silently discarded.  
> That would cause the breakpoint to "work" but it won't only stop on one 
> queue. So I see:
> 
> 
> (lldb) break set -f main.c -l 10 -q whatever
> Breakpoint 1: where = SomeTool`main + 22 at main.c:13:3, address = 
> 0x00010f66
> (lldb) break list 1
> 1: file = 'main.c', line = 10, exact_match = 0, locations = 1, resolved = 1, 
> hit count = 0 Options: enabled queue name: "whatever" 
>   1.1: where = SomeTool`main + 22 at main.c:13:3, address = 
> 0x00010f66, resolved, hit count = 0 
> 
> That's right, it got the queue name and should match against it.  But:
> 
> (lldb) break set -f main.c -l 10 -Q whatever
> Breakpoint 2: where = SomeTool`main + 22 at main.c:13:3, address = 
> 0x00010f66
> (lldb) break list 2
> 2: file = 'main.c', line = 10, exact_match = 0, locations = 1, resolved = 1, 
> hit count = 0
>   2.1: where = SomeTool`main + 22 at main.c:13:3, address = 
> 0x00010f66, resolved, hit count = 0 
> 
> That one didn't get a queue name at all.  So it will always stop, but OTOH 
> that's not really what you wanted.
> 
> It sounds like what is really going on is that the queue matching isn't 
> working as you expected, so when you actually DID set a queue name - using 
> the "-q" option, the breakpoint wasn't stopping, but when you didn't set a 
> queue name (with the bogus -Q option) it did stop.  So there might be 
> something going wrong with the queue name matching?
> 
> Note, this bug doesn't exist in current llvm TOT.  If you try with that lldb:
> 
> (lldb) break set -f foo.c -l 10 -Q foo
> error: unknown or ambiguous option
> 
> That's right, there is no -Q option...
> 
> I'm surprised we have no tests for rejecting illegal options in the command 
> interpreter, but I couldn't find any...
> 
> Jim
> 
> 
> 
> > On Jul 18, 2019, at 4:23 PM, Fernando Bunn via lldb-dev 
> >  wrote:
> > 
> > Hi, everyone.
> > I'm seeing an 

Re: [lldb-dev] Cannot use system debugserver for testing

[Frédéric Riss via lldb-dev]

> On Jul 22, 2019, at 10:14 AM, Gábor Márton  wrote:
> 
> error 18:33:20.280017 +0200   authd   Fatal: interaction not allowed (session 
> has no ui access) (engine 3727)
> This gave me a hint, so I used VPN to have a gui and got a gui window popped 
> up to authenticate lldb. And then I could run lldb as a normal user. Hurray!
> 
> BUT through ssh I still cannot run lldb that as a normal user.

This is by design, debugging as a normal user requires a graphical session. I 
don’t remember in which macOS version this became a requirement, but maybe our 
bots are running an older version?

I’m honestly not sure what the exact constraints are, but I know that I have to 
start a tmux session in a graphical context to be able to run the test suite 
remotely on my machine.

Fred

> I've seen you have 
> ```
> @@@ Setup @@@
> Unlocking keychain /Users/buildslave/Library/Keychains/lldb.keychain-db ... 
> [1;32mOK [0m
> + echo @@
> @@
> ```
> at your build bot at greenlab.
> 
> So I tried "security -v unlock-keychain /Library/Keychains/System.keychain" 
> but that did not work, I believe because scripts/macos-setup-codesign.sh did 
> not ask for a password for the keychain (it asked for pw because of sudo).
> Is this the way to work if I don't have GUI (I must work via SSH, and this 
> ought to be part of a CI) ?
> Should I recreate the keychain with a pw somehow?
> 
> Thanks
> 
> 
> On Mon, Jul 22, 2019 at 6:47 PM Gábor Márton  > wrote:
> Ok, I've done that, here are the logs which happen before the first 
> debugserver error:
> 
> error 18:33:20.236506 +0200   taskgated   cannot open file at line 42270 
> of [95fbac39ba]
> error 18:33:20.236526 +0200   taskgated   os_unix.c:42270: (2) 
> open(/var/db/DetachedSignatures) - No such file or directory
> default   18:33:20.236586 +0200   taskgated   MacOS error: -67062
> error 18:33:20.246771 +0200   taskgated   cannot open file at line 42270 
> of [95fbac39ba]
> error 18:33:20.246787 +0200   taskgated   os_unix.c:42270: (2) 
> open(/var/db/DetachedSignatures) - No such file or directory
> default   18:33:20.246841 +0200   taskgated   MacOS error: -67062
> default   18:33:20.260319 +0200   debugserver debugserver will use 
> os_log for internal logging.
> default   18:33:20.260491 +0200   debugserver 
> debugserver-@(#)PROGRAM:LLDB  PROJECT:lldb-360.99.0
>  for x86_64.
> default   18:33:20.260615 +0200   debugserver Got a connection, 
> waiting for process information for launching or attaching.
> default   18:33:20.264541 +0200   trustd  cert[0]: AnchorTrusted 
> =(leaf)[force]> 0
> default   18:33:20.272256 +0200   trustd  cert[2]: AnchorTrusted 
> =(leaf)[force]> 0
> default   18:33:20.276567 +0200   trustd  cert[2]: AnchorTrusted 
> =(leaf)[force]> 0
> default   18:33:20.278680 +0200   authd   UNIX error exception: 3
> error 18:33:20.279462 +0200   authd   process: PID 27648 failed to create 
> code ref 13
> error 18:33:20.280017 +0200   authd   Fatal: interaction not allowed (session 
> has no ui access) (engine 3727)
> default   18:33:20.280031 +0200   authd   Failed to authorize right 
> 'system.privilege.taskport' by client '/usr/libexec/taskgated' [254] for 
> authorization created by '/usr/libexec/taskgated' [27648] (3,1) (-60007) 
> (engine 3727)
> error 18:33:20.280092 +0200   authd   copy_rights: authorization failed
> error 18:33:20.280442 +0200   debugserver error: 
> MachTask::TaskPortForProcessID task_for_pid failed: ::task_for_pid ( 
> target_tport = 0x0103, pid = 27646, &task ) => err = 0x0005 ((os/kern) 
> failure)
> 
> 
> On Mon, Jul 22, 2019 at 6:10 PM Frédéric Riss  > wrote:
> I think the system logs (in Console.app) would tell us more. Search for 
> debugserver and you should find attach failures. Then remove the filter and 
> look at what happens right before that. There should be a log from taskgated 
> or authd that is a little more explicit about what’s failing.
> 
> Fred 
> 
>> On Jul 22, 2019, at 8:55 AM, Gábor Márton via lldb-dev 
>> mailto:lldb-dev@lists.llvm.org>> wrote:
>> 
>> Some more info: I've stopped lldb (with the system lldb) when " 
>> Process::SetExitStatus (status=-1 (0x), description="Error 1")" is 
>> logged and gathered some more information.
>> Is it possible that some packet types are not implemented?
>> 
>>   * frame #0: 0x7fff599452c6 libsystem_kernel.dylib`__pthread_kill + 10
>> frame #1: 0x7fff59a00bf1 libsystem_pthread.dylib`pthread_kill + 284
>> frame #2: 0x7fff598af6a6 libsystem_c.dylib`abort + 127
>> frame #3: 0x7fff5987820d libsystem_c.dylib`__assert_rtn + 324
>> frame #4: 0x00010b393539 
>> liblldb.10.0.99svn.dylib`lldb_private::Process::SetExitStatus(this=0x7fcfaa470218,
>>  status=-1, cstr="Error 1") at Process.cpp:1149:3
>> frame #5: 0x00010bbd1792 
>> liblldb.10.0.99svn.dylib`lldb_private::process_gdb_

Re: [lldb-dev] [cfe-dev] 8.0.1-final has been tagged

[Hans Wennborg via lldb-dev]

On Fri, Jul 19, 2019 at 8:21 PM Tom Stellard via cfe-dev
 wrote:
>
> Hi,
>
> The 8.0.1 final release has been tagged.  Testers please upload the final
> binaries.

Windows is ready:

$ sha256sum *8.0.1-win*.exe
5d992a41f1ff6296659e66eabbcbaec34f5533fe9d1376fc94fba7450383fe69
LLVM-8.0.1-win32.exe
e3af139c2f93075c13dcbc4091c1311f66fc6e4e8705649fcaf9bef8b3368f41
LLVM-8.0.1-win64.exe

Thanks,
Hans


build_llvm_801-final._bat_
Description: Binary data
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] "error: summary string parsing error" on Fedora 30

[Bob Eastbrook via lldb-dev]

On Fri, Jul 19, 2019 at 4:08 PM Greg Clayton  wrote:

> Sounds like the compiler omitted the type info for std::string. Try "-glldb" 
> in your compiler flags. This tunes debug info for LLDB. A lot of compilers 
> will try to omit types from debug info if the type doesn't originate in the 
> current executable. std::string would be one of those classes. If that flag 
> doesn't work, then you might try -fno-limit-debug-info.

Thanks, Greg.  Using "-g -fno-limit-debug-info" did the trick.  All
works as expected now.  Apparently the versions which ship with Ubuntu
19.04 and Fedora 30 differ with respect to this flag.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] "error: summary string parsing error" on Fedora 30

[Greg Clayton via lldb-dev]

> On Jul 22, 2019, at 1:15 PM, Bob Eastbrook  wrote:
> 
> On Fri, Jul 19, 2019 at 4:08 PM Greg Clayton  wrote:
> 
>> Sounds like the compiler omitted the type info for std::string. Try "-glldb" 
>> in your compiler flags. This tunes debug info for LLDB. A lot of compilers 
>> will try to omit types from debug info if the type doesn't originate in the 
>> current executable. std::string would be one of those classes. If that flag 
>> doesn't work, then you might try -fno-limit-debug-info.
> 
> Thanks, Greg.  Using "-g -fno-limit-debug-info" did the trick.  All works as 
> expected now.  

Great! Glad I could help.

> Apparently the versions which ship with Ubuntu 19.04 and Fedora 30 differ 
> with respect to this flag.

So are you saying "-glldb" is wrong on Fedora but "-fno-limit-debug-info" works?

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

Re: [lldb-dev] Cannot use system debugserver for testing

[Greg Clayton via lldb-dev]

I believe you can run a shell command as root:

$ sudo /usr/sbin/DevToolsSecurity --enable

Then you should be able to debug after that, even on ssh connections.

Greg

> On Jul 22, 2019, at 12:31 PM, Frédéric Riss via lldb-dev 
>  wrote:
> 
> 
> 
>> On Jul 22, 2019, at 10:14 AM, Gábor Márton > > wrote:
>> 
>> error18:33:20.280017 +0200   authd   Fatal: interaction not allowed 
>> (session has no ui access) (engine 3727)
>> This gave me a hint, so I used VPN to have a gui and got a gui window popped 
>> up to authenticate lldb. And then I could run lldb as a normal user. Hurray!
>> 
>> BUT through ssh I still cannot run lldb that as a normal user.
> 
> This is by design, debugging as a normal user requires a graphical session. I 
> don’t remember in which macOS version this became a requirement, but maybe 
> our bots are running an older version?
> 
> I’m honestly not sure what the exact constraints are, but I know that I have 
> to start a tmux session in a graphical context to be able to run the test 
> suite remotely on my machine.
> 
> Fred
> 
>> I've seen you have 
>> ```
>> @@@ Setup @@@
>> Unlocking keychain /Users/buildslave/Library/Keychains/lldb.keychain-db ... 
>> [1;32mOK [0m
>> + echo @@
>> @@
>> ```
>> at your build bot at greenlab.
>> 
>> So I tried "security -v unlock-keychain /Library/Keychains/System.keychain" 
>> but that did not work, I believe because scripts/macos-setup-codesign.sh did 
>> not ask for a password for the keychain (it asked for pw because of sudo).
>> Is this the way to work if I don't have GUI (I must work via SSH, and this 
>> ought to be part of a CI) ?
>> Should I recreate the keychain with a pw somehow?
>> 
>> Thanks
>> 
>> 
>> On Mon, Jul 22, 2019 at 6:47 PM Gábor Márton > > wrote:
>> Ok, I've done that, here are the logs which happen before the first 
>> debugserver error:
>> 
>> error18:33:20.236506 +0200   taskgated   cannot open file at 
>> line 42270 of [95fbac39ba]
>> error18:33:20.236526 +0200   taskgated   os_unix.c:42270: (2) 
>> open(/var/db/DetachedSignatures) - No such file or directory
>> default  18:33:20.236586 +0200   taskgated   MacOS error: -67062
>> error18:33:20.246771 +0200   taskgated   cannot open file at 
>> line 42270 of [95fbac39ba]
>> error18:33:20.246787 +0200   taskgated   os_unix.c:42270: (2) 
>> open(/var/db/DetachedSignatures) - No such file or directory
>> default  18:33:20.246841 +0200   taskgated   MacOS error: -67062
>> default  18:33:20.260319 +0200   debugserver debugserver will use 
>> os_log for internal logging.
>> default  18:33:20.260491 +0200   debugserver 
>> debugserver-@(#)PROGRAM:LLDB  PROJECT:lldb-360.99.0
>>  for x86_64.
>> default  18:33:20.260615 +0200   debugserver Got a connection, 
>> waiting for process information for launching or attaching.
>> default  18:33:20.264541 +0200   trustd  cert[0]: AnchorTrusted 
>> =(leaf)[force]> 0
>> default  18:33:20.272256 +0200   trustd  cert[2]: AnchorTrusted 
>> =(leaf)[force]> 0
>> default  18:33:20.276567 +0200   trustd  cert[2]: AnchorTrusted 
>> =(leaf)[force]> 0
>> default  18:33:20.278680 +0200   authd   UNIX error exception: 3
>> error18:33:20.279462 +0200   authd   process: PID 27648 failed to 
>> create code ref 13
>> error18:33:20.280017 +0200   authd   Fatal: interaction not allowed 
>> (session has no ui access) (engine 3727)
>> default  18:33:20.280031 +0200   authd   Failed to authorize right 
>> 'system.privilege.taskport' by client '/usr/libexec/taskgated' [254] for 
>> authorization created by '/usr/libexec/taskgated' [27648] (3,1) (-60007) 
>> (engine 3727)
>> error18:33:20.280092 +0200   authd   copy_rights: authorization 
>> failed
>> error18:33:20.280442 +0200   debugserver error: 
>> MachTask::TaskPortForProcessID task_for_pid failed: ::task_for_pid ( 
>> target_tport = 0x0103, pid = 27646, &task ) => err = 0x0005 ((os/kern) 
>> failure)
>> 
>> 
>> On Mon, Jul 22, 2019 at 6:10 PM Frédéric Riss > > wrote:
>> I think the system logs (in Console.app) would tell us more. Search for 
>> debugserver and you should find attach failures. Then remove the filter and 
>> look at what happens right before that. There should be a log from taskgated 
>> or authd that is a little more explicit about what’s failing.
>> 
>> Fred 
>> 
>>> On Jul 22, 2019, at 8:55 AM, Gábor Márton via lldb-dev 
>>> mailto:lldb-dev@lists.llvm.org>> wrote:
>>> 
>>> Some more info: I've stopped lldb (with the system lldb) when " 
>>> Process::SetExitStatus (status=-1 (0x), description="Error 1")" is 
>>> logged and gathered some more information.
>>> Is it possible that some packet types are not implemented?
>>> 
>>>   * frame #0: 0x7fff599452c6 libsystem_kernel.dylib`__pthread_kill + 10
>>> frame #1: 0x7fff59a00bf1 lib

Re: [lldb-dev] "error: summary string parsing error" on Fedora 30

[Bob Eastbrook via lldb-dev]

On Mon, Jul 22, 2019 at 1:19 PM Greg Clayton  wrote:

> > Apparently the versions which ship with Ubuntu 19.04 and Fedora 30 differ 
> > with respect to this flag.
>
> So are you saying "-glldb" is wrong on Fedora but "-fno-limit-debug-info" 
> works?

On Fedora 30:

-g: no debug info
-glldb: no debug info
-g -glldb: no debug info
-g -fno-limit-debug-info: debug info present

I'm trying to determine  if "-fno-limit-debug-info" is enabled by
default on Fedora 30, but don't have it it figured out yet.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] "error: summary string parsing error" on Fedora 30

[Greg Clayton via lldb-dev]

> On Jul 22, 2019, at 1:53 PM, Bob Eastbrook  wrote:
> 
> On Mon, Jul 22, 2019 at 1:19 PM Greg Clayton  wrote:
> 
>>> Apparently the versions which ship with Ubuntu 19.04 and Fedora 30 differ 
>>> with respect to this flag.
>> 
>> So are you saying "-glldb" is wrong on Fedora but "-fno-limit-debug-info" 
>> works?
> 
> On Fedora 30:
> 
> -g: no debug info
> -glldb: no debug info
> -g -glldb: no debug info
> -g -fno-limit-debug-info: debug info present
> 
> I'm trying to determine  if "-fno-limit-debug-info" is enabled by
> default on Fedora 30, but don't have it it figured out yet.

Seems like you should fix "-g" so it emits debug info and then try to figure 
this out after that.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 20781] LLDB asserts "Cannot get layout of forward declarations!" from RecordLayoutBuilder.cpp:2782

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=20781

Jonas Devlieghere  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jdevliegh...@apple.com
 Resolution|--- |FIXED

--- Comment #4 from Jonas Devlieghere  ---
jonas@devlieghere /tmp> lldb test2.so
(lldb) target create "test2.so"
Current executable set to 'test2.so' (x86_64).
(lldb) p (bar_t*)0
error: test2.so DWARF DIE at 0x003e (class bar) has a member variable
0x0046 (foo) whose type is a forward declaration, not a complete
definition.
Try compiling the source file with -fstandalone-debug
(bar_t *) $0 = 0x

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 32100] [lldb] Member variables not updating using var objects

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=32100

Jonas Devlieghere  changed:

   What|Removed |Added

 CC||jdevliegh...@apple.com
 Resolution|--- |MOVED
 Status|NEW |RESOLVED

--- Comment #1 from Jonas Devlieghere  ---
lldb-mi is no longer part of the lldb repository.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [9.0.0 Release] The release branch is open; trunk is now 10.0.0

[Brian Cain via lldb-dev]

Uploaded ubuntu 14.

I had to kill some tests executing "lldb-vscode", they had been running for
12+ hours without completing.

b57383860c7e4317b0194d1a91836e01bd637c95
 clang+llvm-8.0.1-x86_64-linux-gnu-ubuntu-14.04.tar.xz

On Thu, Jul 18, 2019 at 7:19 AM Hans Wennborg via Release-testers <
release-test...@lists.llvm.org> wrote:

> Hello everyone,
>
> The release branch for LLVM 9 and its sub-projects was just created
> from trunk at r366426, and the trunk version was subsequently bumped
> to 10.0.0.
>
> Release blockers are tracked by https://llvm.org/PR42474 Please mark
> any bugs, old or new, that need to be fixed before the release as
> blocking that.
>
> To get a change committed to the branch, first commit it to trunk as
> usual, and then request it to be merged --- ideally by filing a
> blocker bug on https://llvm.org/PR42474, or by cc'ing me on the commit
> email. (Please don't request merges over IRC; there's a high risk I'll
> miss them.)
>
> Please help with the release by notifying me about any bugs, commits,
> or other issues you think might be relevant. If it's not already
> tracked as a blocker of the release bug, or I'm not cc'd on an email
> about it, I will probably miss it.
>
> When the branch is in good enough shape, hopefully by tomorrow, the
> first release candidate (RC1) will be tagged and testing can begin.
> The release schedule can be found under "Upcoming Releases" to the
> right at https://llvm.org
>
> Many thanks,
> Hans
> ___
> Release-testers mailing list
> release-test...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
>


-- 
-Brian
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev