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

[Diana Picus via lldb-dev]

ARM & AArch64 ready:
c87b57496f8ec0f0fd74faa1c43b0ac12c156aae54d9be45169fd8f2b33b2181
clang+llvm-8.0.1-armv7a-linux-gnueabihf.tar.xz
a80dc5ca8d9bf5dfb12502263fd50bde6260fe661c1d1f6fb88c7a1146c879f4
clang+llvm-8.0.1-aarch64-linux-gnu.tar.xz

Cheers,
Diana

On Mon, 22 Jul 2019 at 21:40, Hans Wennborg via Release-testers
 wrote:
>
> 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
> ___
> Release-testers mailing list
> release-test...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
___
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

[via lldb-dev]

Behavior of the -g variants is probably better discussed on llvm-dev.
--paulr

> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Greg
> Clayton via lldb-dev
> Sent: Monday, July 22, 2019 5:38 PM
> To: Bob Eastbrook
> Cc: lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] "error: summary string parsing error" on Fedora 30
> 
> 
> 
> > 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 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]

> $ sudo /usr/sbin/DevToolsSecurity --enable
Unfortunately, this did not help.

Anyway, I've found the solution, but took a while.
So, the given scripts/macos-setup-codesign.sh adds a certificate to the
system keychain /Library/Keychains/System.keychain and with a TrustRoot
policy. This explains why could I execute the build lldb (debugserver) only
as root.
So, I tried with a TrustAsRoot policy but that did not work, `security
add-trusted-cert` failed by complaining about the parameters.

Finally, I tried with `debugsign` from ZORG (
https://github.com/llvm/llvm-zorg/tree/master/codesign/debugsign), which
proved to be the approach to follow if we have only SSH access. (Big kudos
for Endre for pointing out that!)
Here is what I did from step to step (if anyone will be in a similar
situation in the future):
- cloned ZORG from github and followed the instructions in the readme.
- Executed `debugsign check`, `debugsign --unsafe setup`.
- Created the a new keychain as described at debugsign's readme. This
resulted the file `~/Library/Keychains/lldb.keychain-db`.
- Created the .p12 file as described in the readme
- Then, `debugsign import`.
- I had to remove the existing "lldb_codesign" from
/Library/Keychains/System.keychain with `sudo security delete-certificate
-c "lldb_codesign" /Library/Keychains/System.keychain` in order to use the
new one from lldb.keychain-db.
- Reboot. I noticed, even if the old cert was removed by
`delete-certificate` the system still used it because macOS does cache the
certificates as stated here
https://lldb.llvm.org/resources/build.html#code-signing-on-macos .
- Lastly and most importantly, after the reboot, we have to unlock the new
keychain: `security unlock-keychain -p lldb_codesign
~/Library/Keychains/lldb.keychain-db` .  According to
http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake the best is to do
unlock the keychain before **every** build! Normally, if we have a gui,
then a popup window requires authentication for using the keychain. But
since we use ssh, `unlock-keychain` is the tool to do the same.

Cheers,
Gabor


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

> 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 <
> lldb-dev@lists.llvm.org> wrote:
>
>
>
> 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.2

[lldb-dev] test suite issue with Python2.7/3.5

[Romaric Jodin via lldb-dev]

Hi everyone,

I'm trying to run the test suite on lldb and I'm having some issues with
Python. I'm on branch 7.0.

When I build lldb, I've got a folder "python3.5/site-packages" generated.
So I believe that the build system found python3 in my environment.
But when I run the testsuite (using "ninja check-lldb"), I've got this
issue:

Traceback (most recent call last):
  File
"/home/rjodin/work/dpu_tools/llvm/lldb/lldb/packages/Python/lldbsuite/test/decorators.py",
line 113, in wrapper
func(*args, **kwargs)
  File
"/home/rjodin/work/dpu_tools/llvm/lldb/lldb/packages/Python/lldbsuite/test/decorators.py",
line 341, in wrapper
return func(self, *args, **kwargs)
  File
"/home/rjodin/work/dpu_tools/llvm/lldb/lldb/packages/Python/lldbsuite/test/functionalities/command_regex/TestCommandRegex.py",
line 39, in test_command_regex
child.expect_exact(prompt)
  File
"/home/rjodin/work/dpu_tools/llvm/lldb/lldb/third_party/Python/module/pexpect-2.4/pexpect.py",
line 1386, in expect_exact
if type(pattern_list) in types.StringTypes or pattern_list in (
AttributeError: module 'types' has no attribute 'StringTypes'

It seems that it's because the code in "pexpect.py" is not compatible with
python3.5.
If I force the system to use python2.7, I've got another issue because of
the way "_lldb.so" is built (with python3.5):

Traceback (most recent call last):
  File "/home/rjodin/work/dpu_tools/llvm/lldb/lldb/test/dotest.py", line 7,
in 
lldbsuite.test.run_suite()
  File
"/home/rjodin/work/dpu_tools/llvm/lldb/lldb/packages/Python/lldbsuite/test/dotest.py",
line 1180, in run_suite
import lldb
  File
"/home/rjodin/package-sdk-2019.3.0/upmem-internal/usr/share/upmem/lib/python3.5/site-packages/lldb/__init__.py",
line 39, in 
import _lldb
ImportError: dynamic module does not define init function (init_lldb)


What do I do wrong?
Thanks,
-- 
*Romaric JODIN*
UPMEM
*Software Engineer*
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] test suite issue with Python2.7/3.5

[Jonas Devlieghere via lldb-dev]

The 7.0 branch is not compatible with Python 3, at least not if you're not
on Windows. The first release that is, would be 9.0, which is currently
being qualified. This includes a bunch of compatibility fixes, and a newer
version of the vendored pexpect (4.6). As you've noticed, using different
versions of Python will not work either.

Your only option is to use Python 2.7, both for building LLDB and for
running the test suite. Making sure the 2.7 interpreter is first in your
PATH should be sufficient. Alternatively, you can explicitly pass
-DPYTHON_EXECUTABLE=/path/to/python27.

Cheers,
Jonas

On Tue, Jul 23, 2019 at 7:38 AM Romaric Jodin via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Hi everyone,
>
> I'm trying to run the test suite on lldb and I'm having some issues with
> Python. I'm on branch 7.0.
>
> When I build lldb, I've got a folder "python3.5/site-packages" generated.
> So I believe that the build system found python3 in my environment.
> But when I run the testsuite (using "ninja check-lldb"), I've got this
> issue:
>
> Traceback (most recent call last):
>   File
> "/home/rjodin/work/dpu_tools/llvm/lldb/lldb/packages/Python/lldbsuite/test/decorators.py",
> line 113, in wrapper
> func(*args, **kwargs)
>   File
> "/home/rjodin/work/dpu_tools/llvm/lldb/lldb/packages/Python/lldbsuite/test/decorators.py",
> line 341, in wrapper
> return func(self, *args, **kwargs)
>   File
> "/home/rjodin/work/dpu_tools/llvm/lldb/lldb/packages/Python/lldbsuite/test/functionalities/command_regex/TestCommandRegex.py",
> line 39, in test_command_regex
> child.expect_exact(prompt)
>   File
> "/home/rjodin/work/dpu_tools/llvm/lldb/lldb/third_party/Python/module/pexpect-2.4/pexpect.py",
> line 1386, in expect_exact
> if type(pattern_list) in types.StringTypes or pattern_list in (
> AttributeError: module 'types' has no attribute 'StringTypes'
>
> It seems that it's because the code in "pexpect.py" is not compatible with
> python3.5.
> If I force the system to use python2.7, I've got another issue because of
> the way "_lldb.so" is built (with python3.5):
>
> Traceback (most recent call last):
>   File "/home/rjodin/work/dpu_tools/llvm/lldb/lldb/test/dotest.py", line
> 7, in 
> lldbsuite.test.run_suite()
>   File
> "/home/rjodin/work/dpu_tools/llvm/lldb/lldb/packages/Python/lldbsuite/test/dotest.py",
> line 1180, in run_suite
> import lldb
>   File
> "/home/rjodin/package-sdk-2019.3.0/upmem-internal/usr/share/upmem/lib/python3.5/site-packages/lldb/__init__.py",
> line 39, in 
> import _lldb
> ImportError: dynamic module does not define init function (init_lldb)
>
>
> What do I do wrong?
> Thanks,
> --
> *Romaric JODIN*
> UPMEM
> *Software Engineer*
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
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

[Brian Cain via lldb-dev]

[previously I misdirected this message as a reply to the 9.0.0 thread, so
I'm reproducing here just in case]

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 Fri, Jul 19, 2019 at 10:21 PM Tom Stellard via Release-testers <
release-test...@lists.llvm.org> wrote:

> Hi,
>
> The 8.0.1 final release has been tagged.  Testers please upload the final
> binaries.
>
> -Tom
> ___
> 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

[lldb-dev] [Bug 42724] New: lldb fails to build on windows with RegisterContextWindows_x64.cpp(297): error C2039: 'Rax': is not a member of '_CONTEXT'

[via lldb-dev]

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

Bug ID: 42724
   Summary: lldb fails to build on windows with
RegisterContextWindows_x64.cpp(297): error C2039:
'Rax': is not a member of '_CONTEXT'
   Product: lldb
   Version: 9.0
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: release blocker
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: h...@chromium.org
CC: amcca...@google.com, jdevliegh...@apple.com,
lab...@google.com, llvm-b...@lists.llvm.org
Blocks: 42474

>From trying to do a 32-bit Windows build of the release_90 branch:


C:\PROGRA~2\MIB055~1\2017\PROFES~1\VC\Tools\MSVC\1412~1.258\bin\Hostx86\x86\cl.exe
 /nologo /TP -DGTEST_HAS_RTTI=0 -DLLDB_CONFIGURATION_RELEASE
-DLLDB_DISABLE_CURSES -DLLDB_DISABLE_LIBEDIT -DUNICODE
-D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NONSTDC_NO_WARNINGS
-D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS
-D_ENABLE_EXTENDED_ALIGNED_STORAGE -D_FILE_OFFSET_BITS=64 -D_HAS_EXCEPTIONS=0
-D_LARGEFILE_SOURCE -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS
-D_UNICODE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS -Itools\lldb\source\Plugins\Process\Windows\Common
-IC:\src\llvm_package_900-rc1\llvm\tools\lldb\source\Plugins\Process\Windows\Common
-Itools\lldb\source -Itools\lldb\include
-IC:\src\llvm_package_900-rc1\llvm\tools\lldb\include -Iinclude
-IC:\src\llvm_package_900-rc1\llvm\include
-IC:\Users\hwennborg\AppData\Local\Programs\Python\Python36-32\Include
-IC:\src\llvm_package_900-rc1\llvm\tools\clang\include
-Itools\lldb\..\clang\include
-IC:\src\llvm_package_900-rc1\llvm\tools\lldb\source\. /DWIN32 /D_WINDOWS  
/Zc:inline /Zc:strictStrings /Oi /Zc:rvalueCast /W4 -wd4141 -wd4146 -wd4180
-wd4244 -wd4258 -wd4267 -wd4291 -wd4345 -wd4351 -wd4456 -wd4457 -wd4458 -wd4459
-wd4503 -wd4624 -wd4722 -wd4100 -wd4127 -wd4512 -wd4505 -wd4610 -wd4510 -wd4702
-wd4245 -wd4706 -wd4310 -wd4701 -wd4703 -wd4389 -wd4611 -wd4805 -wd4204 -wd4577
-wd4091 -wd4592 -wd4319 -wd4709 -wd4324 -w14062 -we4238 /MD /O1 /Ob1   -UNDEBUG
-wd4018 -wd4068 -wd4150 -wd4201 -wd4251 -wd4521 -wd4530  /EHs-c- /GR-
/showIncludes
/Fotools\lldb\source\Plugins\Process\Windows\Common\CMakeFiles\lldbPluginProcessWindowsCommon.dir\x64\RegisterContextWindows_x64.cpp.obj
/Fdtools\lldb\source\Plugins\Process\Windows\Common\CMakeFiles\lldbPluginProcessWindowsCommon.dir\lldbPluginProcessWindowsCommon.pdb
/FS -c
C:\src\llvm_package_900-rc1\llvm\tools\lldb\source\Plugins\Process\Windows\Common\x64\RegisterContextWindows_x64.cpp
C:\src\llvm_package_900-rc1\llvm\tools\lldb\source\Plugins\Process\Windows\Common\x64\RegisterContextWindows_x64.cpp(297):
error C2039: 'Rax': is not a member of '_CONTEXT'
C:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\um\winnt.h(7548):
note: see declaration of '_CONTEXT'
C:\src\llvm_package_900-rc1\llvm\tools\lldb\source\Plugins\Process\Windows\Common\x64\RegisterContextWindows_x64.cpp(300):
error C2039: 'Rbx': is not a member of '_CONTEXT'
C:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\um\winnt.h(7548):
note: see declaration of '_CONTEXT'
C:\src\llvm_package_900-rc1\llvm\tools\lldb\source\Plugins\Process\Windows\Common\x64\RegisterContextWindows_x64.cpp(303):
error C2039: 'Rcx': is not a member of '_CONTEXT'
C:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\um\winnt.h(7548):
note: see declaration of '_CONTEXT'
C:\src\llvm_package_900-rc1\llvm\tools\lldb\source\Plugins\Process\Windows\Common\x64\RegisterContextWindows_x64.cpp(306):
error C2039: 'Rdx': is not a member of '_CONTEXT'
C:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\um\winnt.h(7548):
note: see declaration of '_CONTEXT'
C:\src\llvm_package_900-rc1\llvm\tools\lldb\source\Plugins\Process\Windows\Common\x64\RegisterContextWindows_x64.cpp(309):
error C2039: 'Rdi': is not a member of '_CONTEXT'
C:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\um\winnt.h(7548):
note: see declaration of '_CONTEXT'
C:\src\llvm_package_900-rc1\llvm\tools\lldb\source\Plugins\Process\Windows\Common\x64\RegisterContextWindows_x64.cpp(312):
error C2039: 'Rsi': is not a member of '_CONTEXT'
C:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\um\winnt.h(7548):
note: see declaration of '_CONTEXT'
C:\src\llvm_package_900-rc1\llvm\tools\lldb\source\Plugins\Process\Windows\Common\x64\RegisterContextWindows_x64.cpp(315):
error C2039: 'R8': is not a member of '_CONTEXT'
C:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\um\winnt.h(7548):
note: see declaration of '_CONTEXT'
C:\src\llvm_package_900-rc1\llvm\tools\lldb\source\Plugins\Process\Windows\Common\x64\RegisterContextWindows_x64.cpp(318):
error C2039: 'R9': is not a member of '_CONTEXT'
C:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\um\winnt.h(7548):
note: see declaration of '_CONTEXT'
C

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

[Ted Woodward via lldb-dev]

We saw the same thing internally. We don’t use lldb-vscode, so we turned off 
those tests.

Greg, any thoughts on lldb-vscode tests running forever on Linux?

From: lldb-dev  On Behalf Of Brian Cain via 
lldb-dev
Sent: Monday, July 22, 2019 10:44 PM
To: Hans Wennborg 
Cc: llvm-dev ; Release-testers 
; clangd-...@lists.llvm.org; openmp-dev 
(openmp-...@lists.llvm.org) ; LLDB Dev 
; cfe-dev ; 
libcxx-...@lists.llvm.org
Subject: [EXT] Re: [lldb-dev] [Release-testers] [9.0.0 Release] The release 
branch is open; trunk is now 10.0.0

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 
mailto: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

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

[Greg Clayton via lldb-dev]

Maybe https://reviews.llvm.org/D65163  will 
fix this issue?

> On Jul 23, 2019, at 11:57 AM, Ted Woodward  wrote:
> 
> We saw the same thing internally. We don’t use lldb-vscode, so we turned off 
> those tests.
>  
> Greg, any thoughts on lldb-vscode tests running forever on Linux?
>  
> From: lldb-dev  On Behalf Of Brian Cain via 
> lldb-dev
> Sent: Monday, July 22, 2019 10:44 PM
> To: Hans Wennborg 
> Cc: llvm-dev ; Release-testers 
> ; clangd-...@lists.llvm.org; openmp-dev 
> (openmp-...@lists.llvm.org) ; LLDB Dev 
> ; cfe-dev ; 
> libcxx-...@lists.llvm.org
> Subject: [EXT] Re: [lldb-dev] [Release-testers] [9.0.0 Release] The release 
> branch is open; trunk is now 10.0.0
>  
> 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 
> mailto: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

[lldb-dev] Evaluate expression for template class

[Scott Funkenhauser via lldb-dev]

Hey,

I've noticed that evaluating expressions involving templated classes seems
to have some unexpected behavior.

I've created the following sample code to reproduce the issue:

template  class foo
{
  uint32_t data;
};

foo test;

int main() {
  foo test2;
  return 0;
}

I've set a breakpoint on main and evaluated the following expressions:
(lldb) p sizeof(foo)
(unsigned long) $0 = 4
(lldb) p sizeof(foo)
error: implicit instantiation of undefined template 'foo'
template is declared here

It seems like expression evaluation can only find the specialized templated
classes that were used in the current scope. Running the same example using
GDB works as expected (both expressions are evaluated correctly).

Is this a known issue?
Does anybody have any insight, or familiarity with expression
evaluation that would be able to point me in the right direction?

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

Re: [lldb-dev] Evaluate expression for template class

[Jim Ingham via lldb-dev]

lldb can't currently create new template instantiations.  It can only access 
ones that were generated in the binary you were debugging.  The debug 
information doesn't have any code, so we can't create new instantiations from 
there.  Having the debugger try to include headers into the expression context 
in the same way the compiler did originally is also tricky since we don't know 
the header search paths or defines that the compiler used when it built the 
template instantiations...  Raphael has been working on doing this for the case 
where the C++ code is build into a clang module, but I don't think that work is 
done yet, and then you have to build your code with modules to use it...

The  expression is failing because clang is being smart and sees that 
though you mention foo in reference to "test" you never actually use 
"test", so it doesn't actually have to make that instantiation. In the case 
where this works with gdb, did you build with clang or did you build with gcc?  
If the latter, this might be working for gdb because gcc emits code for the int 
template instantiation when you mention it, rather than only when you use it?

Does it also work for gdb when you try:

(gdb) p sizeof(foo)

or any other type you haven't mentioned in your code?

Not that that really matters for what lldb would have to do, but it would be 
interesting to know...

Jim



> On Jul 23, 2019, at 4:22 PM, Scott Funkenhauser via lldb-dev 
>  wrote:
> 
> Hey,
> 
> I've noticed that evaluating expressions involving templated classes seems to 
> have some unexpected behavior.
> 
> I've created the following sample code to reproduce the issue: 
> 
> template  class foo
> { 
>   uint32_t data;
> };
> 
> foo test;
> 
> int main() {
>   foo test2;
>   return 0;
> }
> 
> I've set a breakpoint on main and evaluated the following expressions:
> (lldb) p sizeof(foo)
> (unsigned long) $0 = 4
> (lldb) p sizeof(foo)
> error: implicit instantiation of undefined template 'foo'
> template is declared here
> 
> It seems like expression evaluation can only find the specialized templated 
> classes that were used in the current scope. Running the same example using 
> GDB works as expected (both expressions are evaluated correctly).
> 
> Is this a known issue?
> Does anybody have any insight, or familiarity with expression evaluation that 
> would be able to point me in the right direction?
> 
> Thanks,
> Scott
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

Re: [lldb-dev] Evaluate expression for template class

[Scott Funkenhauser via lldb-dev]

I built with both clang and gcc, the behavior is the same (lldb fails to
evaluate the expression, gdb succeeds).

Trying to evaluate a template type that hasn't been instantiated fails in
both lldb and gdb.
ie.
(gdb) p sizeof(foo)
No symbol "foo" in current context.
(lldb) p sizeof(foo)
error: implicit instantiation of undefined template 'foo'
template is declared here

Looking at the debug info, both template instantiations are there, it seems
like LLDB just isn't finding it (while GDB is).

 $readelf --debug-dump a.out | grep foo
  0x 666f6f00 5400696e 7400666f 6f3c696e foo.T.int.foo
<41>   DW_AT_name: (indirect string, offset: 0xa): foo
<49>   DW_AT_name: (indirect string, offset: 0x0): foo
<8f>   DW_AT_name: (indirect string, offset: 0x87): foo
<97>   DW_AT_name: (indirect string, offset: 0x0): foo
8d foo
3f foo

On Tue, Jul 23, 2019 at 8:35 PM Jim Ingham  wrote:

> lldb can't currently create new template instantiations.  It can only
> access ones that were generated in the binary you were debugging.  The
> debug information doesn't have any code, so we can't create new
> instantiations from there.  Having the debugger try to include headers into
> the expression context in the same way the compiler did originally is also
> tricky since we don't know the header search paths or defines that the
> compiler used when it built the template instantiations...  Raphael has
> been working on doing this for the case where the C++ code is build into a
> clang module, but I don't think that work is done yet, and then you have to
> build your code with modules to use it...
>
> The  expression is failing because clang is being smart and sees that
> though you mention foo in reference to "test" you never actually use
> "test", so it doesn't actually have to make that instantiation. In the case
> where this works with gdb, did you build with clang or did you build with
> gcc?  If the latter, this might be working for gdb because gcc emits code
> for the int template instantiation when you mention it, rather than only
> when you use it?
>
> Does it also work for gdb when you try:
>
> (gdb) p sizeof(foo)
>
> or any other type you haven't mentioned in your code?
>
> Not that that really matters for what lldb would have to do, but it would
> be interesting to know...
>
> Jim
>
>
>
> > On Jul 23, 2019, at 4:22 PM, Scott Funkenhauser via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Hey,
> >
> > I've noticed that evaluating expressions involving templated classes
> seems to have some unexpected behavior.
> >
> > I've created the following sample code to reproduce the issue:
> >
> > template  class foo
> > {
> >   uint32_t data;
> > };
> >
> > foo test;
> >
> > int main() {
> >   foo test2;
> >   return 0;
> > }
> >
> > I've set a breakpoint on main and evaluated the following expressions:
> > (lldb) p sizeof(foo)
> > (unsigned long) $0 = 4
> > (lldb) p sizeof(foo)
> > error: implicit instantiation of undefined template 'foo'
> > template is declared here
> >
> > It seems like expression evaluation can only find the specialized
> templated classes that were used in the current scope. Running the same
> example using GDB works as expected (both expressions are evaluated
> correctly).
> >
> > Is this a known issue?
> > Does anybody have any insight, or familiarity with expression evaluation
> that would be able to point me in the right direction?
> >
> > Thanks,
> > Scott
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Evaluate expression for template class

[Jim Ingham via lldb-dev]

Interesting...  What lldb & clang were you using?  With current TOT clang & 
lldb I see:

(lldb) run
Process 83732 launched: '/tmp/template2' (x86_64)
Process 83732 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
frame #0: 0x00010fad template2`main at template.cpp:12
   9
   10   int main() {
   11 foo test2;
-> 12 return 0;
  ^
   13   }

(lldb) expr sizeof(test)
(unsigned long) $0 = 4
(lldb) expr sizeof(test2)
(unsigned long) $1 = 4

That's good, we do know about both of these, but:

(lldb) expr sizeof(foo)
error: use of undeclared identifier 'foo'
error: expected '(' for function-style cast or type construction
error: expected expression
(lldb) expr sizeof(foo)
error: use of undeclared identifier 'foo'
error: expected '(' for function-style cast or type construction
error: expected expression

Jim


> On Jul 23, 2019, at 5:49 PM, Scott Funkenhauser  
> wrote:
> 
> I built with both clang and gcc, the behavior is the same (lldb fails to 
> evaluate the expression, gdb succeeds).
> 
> Trying to evaluate a template type that hasn't been instantiated fails in 
> both lldb and gdb.
> ie.
> (gdb) p sizeof(foo)
> No symbol "foo" in current context.
> (lldb) p sizeof(foo)
> error: implicit instantiation of undefined template 'foo'
> template is declared here
> 
> Looking at the debug info, both template instantiations are there, it seems 
> like LLDB just isn't finding it (while GDB is).
> 
>  $readelf --debug-dump a.out | grep foo
>   0x 666f6f00 5400696e 7400666f 6f3c696e foo.T.int.foo   0x0080 00746573 74320066 6f6f3c76 6f69643e .test2.foo
> <41>   DW_AT_name: (indirect string, offset: 0xa): foo
> <49>   DW_AT_name: (indirect string, offset: 0x0): foo
> <8f>   DW_AT_name: (indirect string, offset: 0x87): foo
> <97>   DW_AT_name: (indirect string, offset: 0x0): foo
> 8dfoo
> 3ffoo
> 
> On Tue, Jul 23, 2019 at 8:35 PM Jim Ingham  wrote:
> lldb can't currently create new template instantiations.  It can only access 
> ones that were generated in the binary you were debugging.  The debug 
> information doesn't have any code, so we can't create new instantiations from 
> there.  Having the debugger try to include headers into the expression 
> context in the same way the compiler did originally is also tricky since we 
> don't know the header search paths or defines that the compiler used when it 
> built the template instantiations...  Raphael has been working on doing this 
> for the case where the C++ code is build into a clang module, but I don't 
> think that work is done yet, and then you have to build your code with 
> modules to use it...
> 
> The  expression is failing because clang is being smart and sees that 
> though you mention foo in reference to "test" you never actually use 
> "test", so it doesn't actually have to make that instantiation. In the case 
> where this works with gdb, did you build with clang or did you build with 
> gcc?  If the latter, this might be working for gdb because gcc emits code for 
> the int template instantiation when you mention it, rather than only when you 
> use it?
> 
> Does it also work for gdb when you try:
> 
> (gdb) p sizeof(foo)
> 
> or any other type you haven't mentioned in your code?
> 
> Not that that really matters for what lldb would have to do, but it would be 
> interesting to know...
> 
> Jim
> 
> 
> 
> > On Jul 23, 2019, at 4:22 PM, Scott Funkenhauser via lldb-dev 
> >  wrote:
> > 
> > Hey,
> > 
> > I've noticed that evaluating expressions involving templated classes seems 
> > to have some unexpected behavior.
> > 
> > I've created the following sample code to reproduce the issue: 
> > 
> > template  class foo
> > { 
> >   uint32_t data;
> > };
> > 
> > foo test;
> > 
> > int main() {
> >   foo test2;
> >   return 0;
> > }
> > 
> > I've set a breakpoint on main and evaluated the following expressions:
> > (lldb) p sizeof(foo)
> > (unsigned long) $0 = 4
> > (lldb) p sizeof(foo)
> > error: implicit instantiation of undefined template 'foo'
> > template is declared here
> > 
> > It seems like expression evaluation can only find the specialized templated 
> > classes that were used in the current scope. Running the same example using 
> > GDB works as expected (both expressions are evaluated correctly).
> > 
> > Is this a known issue?
> > Does anybody have any insight, or familiarity with expression evaluation 
> > that would be able to point me in the right direction?
> > 
> > Thanks,
> > Scott
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 

___
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

[Brian Cain via lldb-dev]

Uploaded SLES11.

a18ac0820acf7e4b19b917a143868a73ddb30a02
 clang+llvm-8.0.1-x86_64-linux-sles11.3.tar.xz

On Tue, Jul 23, 2019 at 10:10 AM Brian Cain  wrote:

> [previously I misdirected this message as a reply to the 9.0.0 thread, so
> I'm reproducing here just in case]
>
> 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 Fri, Jul 19, 2019 at 10:21 PM Tom Stellard via Release-testers <
> release-test...@lists.llvm.org> wrote:
>
>> Hi,
>>
>> The 8.0.1 final release has been tagged.  Testers please upload the final
>> binaries.
>>
>> -Tom
>> ___
>> Release-testers mailing list
>> release-test...@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
>>
>
>
> --
> -Brian
>


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