[lldb-dev] [Bug 44053] New: lldb can't run static initializers on AArch64 Ubuntu
https://bugs.llvm.org/show_bug.cgi?id=44053
Bug ID: 44053
Summary: lldb can't run static initializers on AArch64 Ubuntu
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: diana.pi...@linaro.org
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org
TestStaticInitializers.py fails on AArch64 Linux for dwarf and dwo with:
runCmd: expr -p -- struct Foo { Foo() { inc_counter(); } }; Foo f;
runCmd failed!
error: couldn't run static initializers: couldn't run static initializer:
FAILURE
FAIL: LLDB (/home/diana.picus/llvm-envs/lldb/build/bin/clang-10-aarch64) ::
test_dwo (TestStaticInitializers.StaticInitializers)
>>: success
--
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 44055] New: TestRequireHWBreakpoints.py fails on AArch64 Ubuntu
https://bugs.llvm.org/show_bug.cgi?id=44055 Bug ID: 44055 Summary: TestRequireHWBreakpoints.py fails on AArch64 Ubuntu Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: diana.pi...@linaro.org CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org 'thread step-over', 'step-out', 'step-in' and 'until' all seem to return success, although an error is expected after setting target.require-hardware-breakpoint to true. FAILURE FAIL: LLDB (/home/diana.picus/llvm-envs/lldb/build/bin/clang-10-aarch64) :: test_step_out (TestRequireHWBreakpoints.BreakpointLocationsTestCase) >>: success -- 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 44056] New: python _lldb.so is a broken symlink on regular Linux distro packages
https://bugs.llvm.org/show_bug.cgi?id=44056 Bug ID: 44056 Summary: python _lldb.so is a broken symlink on regular Linux distro packages Product: lldb Version: 9.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: thi...@kde.org CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org Ref: https://github.com/clearlinux/distribution/issues/1502 The $PYTHONSITEDIR/lldb/_lldb.so file is a symlink to $LIBDIR/liblldb.so, but the .so file is usually not included in regular packages, only development ones. That makes the symlink broken. Fedora workaround: https://src.fedoraproject.org/rpms/lldb/blob/master/f/lldb.spec#_94 OpenSUSE workaround: https://build.opensuse.org/package/view_file/openSUSE:Factory/llvm9/llvm9.spec?expand=1 line 896 Clear Linux workaround: https://github.com/clearlinux-pkgs/lldb/blob/9.0.0-3/install_append -- 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 44057] New: Incorrect stepping through inlined function on AArch64 Ubuntu
https://bugs.llvm.org/show_bug.cgi?id=44057 Bug ID: 44057 Summary: Incorrect stepping through inlined function on AArch64 Ubuntu Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: diana.pi...@linaro.org CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org Created attachment 22839 --> https://bugs.llvm.org/attachment.cgi?id=22839&action=edit Log of stepping from caller_trivial_1 into caller_trivial_2 TestInlineStepping.py fails on AArch64: AssertionError: Step into stopped at wrong place: expected: /home/buildslave/buildslave/lldb-cmake-aarch64/llvm-project/lldb/packages/Python/lldbsuite/test/functionalities/inline-stepping/calling.cpp:78 got: /home/buildslave/buildslave/lldb-cmake-aarch64/llvm-project/lldb/packages/Python/lldbsuite/test/functionalities/inline-stepping/calling.cpp:98:18. -- 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 44059] New: The LLDB test for the entry values will fail due to changes in the compiler
https://bugs.llvm.org/show_bug.cgi?id=44059 Bug ID: 44059 Summary: The LLDB test for the entry values will fail due to changes in the compiler Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: djordje.todoro...@rt-rk.com CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org The test will be disabled (temporarily), since we are trying to change the approach for production of the entry values. The D68206 is the first patch from the set of patches. -- 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 44068] New: LLDB Not Stepping into Multiple Inheritance Virtual Functions
https://bugs.llvm.org/show_bug.cgi?id=44068
Bug ID: 44068
Summary: LLDB Not Stepping into Multiple Inheritance Virtual
Functions
Product: lldb
Version: 9.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: acwilso...@gmail.com
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org
Created attachment 22842
--> https://bugs.llvm.org/attachment.cgi?id=22842&action=edit
Reproducer program.
Overview:
Using LLDB to debug polymorphic objects that have multiple inheritance will not
step into virtual functions.
Steps to Reproduce:
```
$ clang++ -std=c++11 -g -O0 reproducer.cpp -o clang.out
$ lldb clang.out
(lldb) target create "clang.out"
Current executable set to 'clang.out' (x86_64).
(lldb) b 36
Breakpoint 1: where = clang.out`main + 103 at
reproducer.cpp:36:16, address = 0x00400d67
(lldb) r
Process 2764 launched: '/home/rdtscp/Documents/lldb_reproducer/clang.out'
(x86_64)
Process 2764 stopped
* thread #1, name = 'clang.out', stop reason = breakpoint 1.1
frame #0: 0x00400d67 clang.out`main(argc=1,
argv=0x7fffe808) at reproducer.cpp:36:16
33 int main(int argc, char **argv) {
34 using namespace Test;
35 std::shared_ptr object = std::shared_ptr(new
Concrete());
-> 36 int output = object->vFun();
37 std::cout << output << std::endl;
38 return output;
39 }
(lldb) s
Process 2764 stopped
* thread #1, name = 'clang.out', stop reason = step in
frame #0: 0x00400d86 clang.out`main(argc=1,
argv=0x7fffe808) at reproducer.cpp:37:16
34 using namespace Test;
35 std::shared_ptr object = std::shared_ptr(new
Concrete());
36 int output = object->vFun();
-> 37 std::cout << output << std::endl;
38 return output;
39 }
(lldb)
```
Altering the `Concrete` class to be:
```
class Concrete : // public Base,
public Interface {
public:
virtual int vFun() override {
volatile int x = rand();
if (x > 0)
return x;
else
return 0;
}
};
```
Will result in:
```
$ clang++ -std=c++11 -g -O0 reproducer.cpp -o clang.out
$ lldb clang.out
(lldb) target create "clang.out"
Current executable set to 'clang.out' (x86_64).
(lldb) b 36
Breakpoint 1: where = clang.out`main + 104 at reproducer.cpp:36:16, address =
0x00400cf8
(lldb) r
Process 2869 launched: '/home/rdtscp/Documents/lldb_reproducer/clang.out'
(x86_64)
Process 2869 stopped
* thread #1, name = 'clang.out', stop reason = breakpoint 1.1
frame #0: 0x00400cf8 clang.out`main(argc=1,
argv=0x7fffe808) at reproducer.cpp:36:16
33 int main(int argc, char **argv) {
34 using namespace Test;
35 std::shared_ptr object = std::shared_ptr(new
Concrete());
-> 36 int output = object->vFun();
37 std::cout << output << std::endl;
38 return output;
39 }
(lldb) s
Process 2869 stopped
* thread #1, name = 'clang.out', stop reason = step in
frame #0: 0x00400fec
clang.out`Test::Concrete::vFun(this=0x00615c20) at reproducer.cpp:23:24
20 public Interface {
21 public:
22 virtual int vFun() override {
-> 23 volatile int x = rand();
24 if (x > 0)
25 return x;
26 else
(lldb)
```
The above shows that making the `Concrete` class inherit from the `Base` class
prevents us from stepping into `vFun()`.
System Settings:
```
OS: Debian GNU/Linux 9.11 (stretch) x86_64
Model: VirtualBox 1.2
Kernel: 4.9.0-11-amd64
Uptime: 1 hour, 3 minutes
Packages: 1722
Shell: zsh 5.3.1
CPU: Intel i5-7360U (1) @ 2.3GHz
GPU: VMware SVGA II Adapter
Memory: 219MB / 996MB
```
```
$ clang++ --version
clang version 9.0.0-svn364966-1~exp1+0~20190702204433.1332~1.gbpb44072 (trunk)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
$ lldb --version
lldb version 9.0.0
```
Additional Information:
I tried using:
```
g++ (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
```
To see if my code was incorrect, but g++ and gdb were able to step into
"vFun()" fun.
--
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] RFC: Using GitHub Actions for CI testing on the release/* branches
On 11/11/2019 04:32 PM, Tom Stellard wrote: > Hi, > > I would like to start using GitHub Actions[1] for CI testing on the release/* > branches. As far as I know we don't have any buildbots listening to the > release branches, and I think GitHub Actions are a good way for us to quickly > bring-up some CI jobs there. > > My proposal is to start by adding two post-commit CI jobs to the release/9.x > branch. > One for building and testing (ninja checka-all) llvm/clang/lld on Linux, > Windows, and Mac, and another for detecting ABI changes since the 9.0.0 > release. > > I have already implemented these two CI jobs in my llvm-project fork on > GitHub[2][3], > but in order to get these running in the main repository, I would need to: > > 1. Create a new repository in the LLVM organization called 'actions' for > storing some custom > builds steps for our CI jobs (see [4]). > 2. Commit yaml CI definitions to the .github/workflows directory in the > release/9.x > branch. > > In the future, I would also like to add buil and tests jobs for other > sub-projects > once I am able to get those working. > > In addition to being used for post-commit testing, having these CI > definitions in the > main tree will make it easier for me (or anyone) to do pre-commit testing for > the > release branch in a personal fork. It will also allow me to experiment with > some new > workflows to help make managing the releases much easier. > > I think this will be a good way to test Actions in a low traffic environment > to > see if they are something we would want to use for CI on the master branch. > > Given that we are close to the end of the 9.0.1 cycle, unless there are any > strong objections, I would like to get this enabled by Mon Nov 18, to > maximize its > usefulness. Let me know what you think. > The CI tests are running now on the stable branch. Here is the first run [1]. Passing commits[2] now have a green check mark in the web UI that you can click on to view the results. These tests have already caught 1 bug that did not appear in my local builds, so they are proving to be very useful. Now that this is in place, I'm going to start looking into some more automation around backporting fixes to the stable branch. I think we could do something like filing backport requests as a GitHub issues and then have that issue automatically trigger a pull request and do some pre-commit testing. I'm still trying to learn what is technically possible with GitHub and if anyone has any ideas or suggestions, let me know. I'm hoping to have something in place for the 10.0.1 release cycle. Thanks, Tom [1] https://github.com/llvm/llvm-project/commit/6c86aa62d502ac2df58e207d4792544cc96d79bd/checks?check_suite_id=316648311 [2] https://github.com/llvm/llvm-project/commit/6c86aa62d502ac2df58e207d4792544cc96d79bd > Thanks, > Tom > > [1] https://github.com/features/actions > [2] > https://github.com/tstellar/llvm-project/commit/952d80e8509ecc95797b2ddbf1af40abad2dcf4e/checks?check_suite_id=305765621 > [3] > https://github.com/tstellar/llvm-project/commit/6d74f1b81632ef081dffa1e0c0434f47d4954423/checks?check_suite_id=303074176 > [4] https://github.com/tstellar/actions > ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Openmp-dev] RFC: Using GitHub Actions for CI testing on the release/* branches
> Hi Tom, > > This sounds very interesting! +1 from me. > What does this imply for the release testers? > Would it be possible / desirable for us to add self-hosted runners for > other architectures? I'm assuming GitHub only provides x86, right? I > totally missed any details about that in their docs, but it seems to > be implied here [1]. I'm not saying we should go all-possible-arches > from the start, we can definitely try it out only for x86 this time > around if you think that would be the best approach. > Nothing changes for release testers at this point. The main goal here is to get some post-commit testing so we can catch issues in the branch early. Longer term I think have self-hosted runners would be great, because it would allow us to fully automate the testing and uploading we do when a release gets tagged. You are correct that GitHub only provides x86 machines, however, they don't have enough disk space (14GB) to be able to run the test-release.sh script, so adding x86 self-hosted builders with more disk space would still be very useful. -Tom > > [1] > https://github.blog/2019-11-05-self-hosted-runners-for-github-actions-is-now-in-beta/ > > Thanks, > Diana ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 43442] LLDB installs Python modules to wrong path on some systems
https://bugs.llvm.org/show_bug.cgi?id=43442 Tom Stellard changed: What|Removed |Added Assignee|lldb-dev@lists.llvm.org |lab...@google.com --- Comment #3 from Tom Stellard --- Pavel, are you OK merging this: https://reviews.llvm.org/rL372835 -- 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
