[lldb-dev] RFC: Update LLVM_VERSION_SUFFIX CMake variable for release candidates

2021-06-29 Thread Tom Stellard via lldb-dev

Hi,

I would like to propose that we start using the LLVM_VERSION_SUFFIX
CMake variable for release candidates.  For example:
after the release/13.x branch is created, instead of changing
LLVM_VERSION_SUFFIX from "git" to "", we would change it to "rc1",
then after the 13.0.0-rc1 release is tagged, we would update the
variable to "rc2", etc. Then right before the final release has been
tagged, we would set it to ""

The library SONAME's currently include LLVM_VERSION_SUFFIX, so this
change will cause each release candidate to have a different SONAME
for libraries.  This is correct for X.Y.0 releases, since it's possible
for a library's ABI to change between release candidates.  However,
for X.Y.1 releases, we do not want to modify the SONAME's at all, so
the build system will need to be updated to accommodate this change.

Ensuring that the SONAME's change when the library ABI's change is
the main motivating reason for proposing this change.  However,
I think in general it is also better for the project to be able to
distinguish between release candidates and final releases.

Note that clang does not currently include LLVM_VERSION_SUFFIX in its
--version output, and I'm not proposing change this as part of this
RFC.

- Tom

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


[lldb-dev] [Bug 50935] New: lldb step over failed in musl dyn exe (Could not create return address breakpoint)

2021-06-29 Thread via lldb-dev
https://bugs.llvm.org/show_bug.cgi?id=50935

Bug ID: 50935
   Summary: lldb step over failed in musl dyn exe (Could not
create return address breakpoint)
   Product: lldb
   Version: 12.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: rprich...@google.com
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org

With a dynamically-linked musl executable (on x86_64 gLinux aka Debian), LLDB
is unable to step over a "printf" call. The problem happens with either PIE or
non-PIE executables, but not with statically-linked musl executables. LLDB is
able to step over this call if I use glibc instead (with either the Debian gcc
or clang compiler).

I tested with both LLDB 12.0.0 and with a current LLDB build from origin/main.

$ cat >test.c <
int main(void) {
  printf("hello!\n");
  return 0;
}
EOF

$ musl-gcc test.c -g
$ file a.out
a.out: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically
linked, interpreter /lib/ld-musl-x86_64.so.1, with debug_info, not stripped

$ /x/clang12/bin/lldb a.out
(lldb) target create "a.out"
Current executable set to '/x/mess/a.out' (x86_64).
(lldb) b main
Breakpoint 1: where = a.out`main + 4 at test.c:3:3, address =
0x1159
(lldb) run
Process 235162 launched: '/x/mess/a.out' (x86_64)
Process 235162 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x5159 a.out`main at test.c:3:3
   1#include 
   2int main(void) {
-> 3  printf("hello!\n");
   4  return 0;
   5}
(lldb) n
Process 235162 stopped
* thread #1, name = 'a.out', stop reason = step over failed (Could not create
return address breakpoint.)
frame #0: 0x5020 a.out`puts
a.out`puts:
->  0x5020 <+0>:  jmpq   *0x2ff2(%rip) ;
_GLOBAL_OFFSET_TABLE_ + 24
0x5026 <+6>:  pushq  $0x0
0x502b <+11>: jmp0x5010

a.out`__libc_start_main:
0x5030 <+0>:  jmpq   *0x2fea(%rip) ;
_GLOBAL_OFFSET_TABLE_ + 32

$ /x/clang12/bin/lldb --version
lldb version 12.0.0 (https://github.com/llvm/llvm-project/ revision
b978a93635b584db380274d7c8963c73989944a1)
  clang revision b978a93635b584db380274d7c8963c73989944a1
  llvm revision b978a93635b584db380274d7c8963c73989944a1

$ musl-gcc --version
cc (Debian 10.2.1-6+build2) 10.2.1 20210110
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ dpkg -l musl
...
ii  musl:amd64 1.2.2-1  amd64standard C library

-- 
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 50936] New: lldb step over glibc dlopen fails (__GI__dl_catch_exception or runs away)

2021-06-29 Thread via lldb-dev
https://bugs.llvm.org/show_bug.cgi?id=50936

Bug ID: 50936
   Summary: lldb step over glibc dlopen fails
(__GI__dl_catch_exception or runs away)
   Product: lldb
   Version: 12.0
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: rprich...@google.com
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org

Using glibc (specifically gLinux aka Debian), LLDB is unable to step over
certain dlopen calls.

In one situation, the library was part of the initial set of needed DSOs, and
LLDB fails with a __GI__dl_catch_exception error. In another situation, the
library isn't loaded already, and when dlopen loads it, LLDB fails to stop
after the dlopen call (and runs to process exit).

Both problems reproduce with either LLVM 12.0.0
(clang+llvm-12.0.0-x86_64-linux-gnu-ubuntu-20.04) or with an upstream Clang and
LLDB that I built today from origin/main.

Test case:

$ cat >test.c <
int main(void) {
  void* ptr;
  dlopen("libm.so.6", RTLD_NOW | RTLD_LOCAL | RTLD_NOLOAD);
  dlopen("libm.so.6", RTLD_NOW | RTLD_LOCAL | RTLD_NOLOAD);
  dlopen("libm.so.6", RTLD_NOW | RTLD_LOCAL | RTLD_NOLOAD);
  dlopen("libm.so.6", RTLD_NOW | RTLD_LOCAL);
  dlopen("libm.so.6", RTLD_NOW | RTLD_LOCAL);
  dlopen("libm.so.6", RTLD_NOW | RTLD_LOCAL);
  return 0;
}
EOF

## Situation 1: __GI__dl_catch_exception (link with -lm)

$ /x/clang12/bin/clang -g test.c -ldl -lm
$ /x/clang12/bin/lldb a.out
(lldb) target create "a.out"
Current executable set to '/x/mess/a.out' (x86_64).
(lldb) b main
Breakpoint 1: where = a.out`main + 15 at test.c:4:3, address =
0x0040113f
(lldb) run
Process 282393 launched: '/x/mess/a.out' (x86_64)
Process 282393 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x0040113f a.out`main at test.c:4:3
   1#include 
   2int main(void) {
   3  void* ptr;
-> 4  dlopen("libm.so.6", RTLD_NOW | RTLD_LOCAL | RTLD_NOLOAD);
   5  dlopen("libm.so.6", RTLD_NOW | RTLD_LOCAL | RTLD_NOLOAD);
   6  dlopen("libm.so.6", RTLD_NOW | RTLD_LOCAL | RTLD_NOLOAD);
   7  dlopen("libm.so.6", RTLD_NOW | RTLD_LOCAL);
(lldb) n
Process 282393 stopped
* thread #1, name = 'a.out', stop reason = step over
frame #0: 0x77dca260
libc.so.6`__GI__dl_catch_exception(exception=0x7fffda40,
operate=0x77fe5ca0, args=0x7fffda60) at
dl-error-skeleton.c:209:18

## Situation 2: process runs away when dlopen loads libm.so.6 (don't link with
-lm)

$ /x/clang12/bin/clang -g test.c -ldl
$ /x/clang12/bin/lldb a.out
(lldb) target create "a.out"
Current executable set to '/x/mess/a.out' (x86_64).
(lldb) b test.c:5
Breakpoint 1: where = a.out`main + 35 at test.c:5:3, address =
0x00401153
(lldb) run
Process 283170 launched: '/x/mess/a.out' (x86_64)
Process 283170 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x00401153 a.out`main at test.c:5:3
   2int main(void) {
   3  void* ptr;
   4  dlopen("libm.so.6", RTLD_NOW | RTLD_LOCAL | RTLD_NOLOAD);
-> 5  dlopen("libm.so.6", RTLD_NOW | RTLD_LOCAL | RTLD_NOLOAD);
   6  dlopen("libm.so.6", RTLD_NOW | RTLD_LOCAL | RTLD_NOLOAD);
   7  dlopen("libm.so.6", RTLD_NOW | RTLD_LOCAL);
   8  dlopen("libm.so.6", RTLD_NOW | RTLD_LOCAL);
(lldb) n
Process 283170 stopped
* thread #1, name = 'a.out', stop reason = step over
frame #0: 0x00401167 a.out`main at test.c:6:3
   3  void* ptr;
   4  dlopen("libm.so.6", RTLD_NOW | RTLD_LOCAL | RTLD_NOLOAD);
   5  dlopen("libm.so.6", RTLD_NOW | RTLD_LOCAL | RTLD_NOLOAD);
-> 6  dlopen("libm.so.6", RTLD_NOW | RTLD_LOCAL | RTLD_NOLOAD);
   7  dlopen("libm.so.6", RTLD_NOW | RTLD_LOCAL);
   8  dlopen("libm.so.6", RTLD_NOW | RTLD_LOCAL);
   9  dlopen("libm.so.6", RTLD_NOW | RTLD_LOCAL);
(lldb) n
Process 283170 stopped
* thread #1, name = 'a.out', stop reason = step over
frame #0: 0x0040117b a.out`main at test.c:7:3
   4  dlopen("libm.so.6", RTLD_NOW | RTLD_LOCAL | RTLD_NOLOAD);
   5  dlopen("libm.so.6", RTLD_NOW | RTLD_LOCAL | RTLD_NOLOAD);
   6  dlopen("libm.so.6", RTLD_NOW | RTLD_LOCAL | RTLD_NOLOAD);
-> 7  dlopen("libm.so.6", RTLD_NOW | RTLD_LOCAL);
   8  dlopen("libm.so.6", RTLD_NOW | RTLD_LOCAL);
   9  dlopen("libm.so.6", RTLD_NOW | RTLD_LOCAL);
   10 return 0;
(lldb) n
Process 283170 exited with status = 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