[lldb-dev] [Bug 51451] New: LLDB AArch64 SVE register context fails to restore after JITTed expression eval
https://bugs.llvm.org/show_bug.cgi?id=51451
Bug ID: 51451
Summary: LLDB AArch64 SVE register context fails to restore
after JITTed expression eval
Product: lldb
Version: 12.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: omair.jav...@linaro.org
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org
Used add_int_arrays_acle example from here:
https://www.linaro.org/blog/how-to-use-lldb-to-debug-sve-enabled-applications/
Used instructions to run on qemu with ubuntu focal where I installed clang-12
and lldb-12 using "apt install".
If I put a breakpoint in the middle of add_int_arrays_acle function, I can read
the SVE registers with "re re". But if I try to read a C variable, the SVE
registers get modified. Here is an example:
Process 298 stopped
* thread #1, name = 'test', stop reason = breakpoint 1.1
frame #0: 0x0040058c
test`add_int_arrays_acle(out=0x0041102c, a=0x0041302c,
b=0x0041502c) at arrays.c:17:3
14
15 pred = svwhilelt_b32(i, (uint64_t)ARRAYSIZE);
16
-> 17 while (svptest_first(svptrue_b32(), pred)) {
^
18 sva = svld1(pred, &a[i]);
19 svb = svld1(pred, &b[i]);
20 svres = svadd_m(pred, sva, svb);
(lldb) re re p0
p0 = {0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11}
(lldb) p i
(uint64_t) $1 = 0
(lldb) re re p0
p0 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00}
(lldb)
I have used the p* registers above as the effect is not visible in the z*
registers unless they have data in the high bits. Here is the example:
(lldb) re write z0 "0x2f 0x2f 0x2f 0x2f 0x2f 0x2f 0x2f 0x2f 0x2f 0x2f 0x2f 0x2f
0x2f 0x2f 0x2f 0x2f 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x01 0x01"
(lldb) re re z0
z0 = {0x2f 0x2f 0x2f 0x2f 0x2f 0x2f 0x2f 0x2f 0x2f 0x2f 0x2f 0x2f 0x2f
0x2f 0x2f 0x2f 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x01 0x01}
(lldb) p i
(uint64_t) $2 = 0
(lldb) re re z0
z0 = {0x2f 0x2f 0x2f 0x2f 0x2f 0x2f 0x2f 0x2f 0x2f 0x2f 0x2f 0x2f 0x2f
0x2f 0x2f 0x2f 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
(lldb)
--
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 51451] LLDB AArch64 SVE register context fails to restore after JITTed expression eval
https://bugs.llvm.org/show_bug.cgi?id=51451 Omair Javaid changed: What|Removed |Added Status|NEW |CONFIRMED Assignee|lldb-dev@lists.llvm.org |omair.jav...@linaro.org --- Comment #1 from Omair Javaid --- I am aware of this issue and will post a tot fix soon. -- 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 51458] New: 'process launch -s' uses gdb-remote connection only if target was created before connecting
https://bugs.llvm.org/show_bug.cgi?id=51458 Bug ID: 51458 Summary: 'process launch -s' uses gdb-remote connection only if target was created before connecting Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: mgo...@gentoo.org CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org Basically: $ ./bin/lldb (lldb) target create a.out Current executable set to '/home/mgorny/git/llvm-project/build/a.out' (x86_64). (lldb) gdb-remote 1234 (lldb) process launch Process 2070224 launched: '/home/mgorny/git/llvm-project/build/a.out' (x86_64) Process 2070224 exited with status = 0 (0x) -> uses remote lldb-server to start the process but: $ ./bin/lldb (lldb) gdb-remote 1234 (lldb) target create a.out Current executable set to '/home/mgorny/git/llvm-project/build/a.out' (x86_64). (lldb) process launch Process 2075735 launched: '/home/mgorny/git/llvm-project/build/a.out' (x86_64) Process 2075735 exited with status = 0 (0x) -> starts a new lldb-server -- 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 51459] New: 'process launch -s' does not work correctly over remote lldb-server
https://bugs.llvm.org/show_bug.cgi?id=51459 Bug ID: 51459 Summary: 'process launch -s' does not work correctly over remote lldb-server Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: mgo...@gentoo.org CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org If I let LLDB start a new instance of lldb-server, I can launch the process stopped: $ ./bin/lldb (lldb) target create a.out Current executable set to '/home/mgorny/git/llvm-project/build/a.out' (x86_64). (lldb) process launch -s Process 2093834 launched: '/home/mgorny/git/llvm-project/build/a.out' (x86_64) (lldb) cont Process 2093834 resuming Process 2093834 exited with status = 0 (0x) but if I use a remote lldb-server, LLDB seems to end up in some weird state that's simultaneously stopped and running: $ ./bin/lldb (lldb) target create a.out Current executable set to '/home/mgorny/git/llvm-project/build/a.out' (x86_64). (lldb) gdb-remote 1234 (lldb) process launch -s Process 2106325 launched: '/home/mgorny/git/llvm-project/build/a.out' (x86_64) (lldb) cont error: Failed to resume process: Resume request failed - process still running.. (lldb) process interrupt error: Failed to halt process: Process is not running. -- 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 51466] New: LLDB can't find function containing a PC from musl libc.so
https://bugs.llvm.org/show_bug.cgi?id=51466
Bug ID: 51466
Summary: LLDB can't find function containing a PC from musl
libc.so
Product: lldb
Version: unspecified
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
On Debian, I compile hello world using "musl-gcc", which links dynamically
against musl's libc.
$ cat hello.c
#include
int main() {
printf("hi\n");
return 0;
}
$ musl-gcc hello.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
The /lib/ld-musl-x86_64.so.1 interpreter is really a symlink to libc.so. (With
musl, the loader and libc.so are the same file.)
$ realpath /lib/ld-musl-x86_64.so.1
/usr/lib/x86_64-linux-musl/libc.so
$ /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 hello.c:4:3, address =
0x1159
(lldb) run
Process 627144 launched: '/x/mess/a.out' (x86_64)
Process 627144 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x5159 a.out`main at hello.c:4:3
1#include
2
3int main() {
-> 4 printf("hi\n");
5 return 0;
6}
(lldb) disas -n exit
libc.so`exit:
0x77f5e090 <+0>: pushq %rbp
0x77f5e091 <+1>: movl %edi, %ebp
0x77f5e093 <+3>: callq 0x77f683e0
0x77f5e098 <+8>: callq 0x77fbfea0
0x77f5e09d <+13>: xorl %eax, %eax
0x77f5e09f <+15>: callq 0x77fa4aa0
0x77f5e0a4 <+20>: movl %ebp, %edi
0x77f5e0a6 <+22>: callq 0x77f68210
(lldb) disas -a 0x77f5e090
error: Could not find function bounds for address 0x77f5e090
(lldb) image show-unwind -n exit
UNWIND PLANS for libc.so`exit (start addr 0x77f5e090)
Asynchronous (not restricted to call-sites) UnwindPlan is 'assembly insn
profiling'
...
(lldb) image show-unwind -a 0x77f5e090
error: no unwind data found that matches '0x77f5e090'.
I think the problem is that "duplicate ld.so instance" special case in
DynamicLoaderPOSIXDYLD.cpp:
ModuleSP module_sp =
LoadModuleAtAddress(I->file_spec, I->link_addr, I->base_addr, true);
if (module_sp.get()) {
if (module_sp->GetObjectFile()->GetBaseAddress().GetLoadAddress(
&m_process->GetTarget()) == m_interpreter_base &&
module_sp != m_interpreter_module.lock()) {
// If this is a duplicate instance of ld.so, unload it. We may end
up
// with it if we load it via a different path than before (symlink
// vs real path).
// TODO: remove this once we either fix library matching or avoid
// loading the interpreter when setting the rendezvous breakpoint.
UnloadSections(module_sp);
loaded_modules.Remove(module_sp);
continue;
}
loaded_modules.AppendIfNeeded(module_sp);
new_modules.Append(module_sp);
}
Adding the duplicate musl module should replace the initial interpreter module
in SectionLoadList. Unloading the duplicate will remove the musl libc from the
SectionLoadList without restoring the original.
Here's some log output that might help:
rprichard@cashew:/x/mess$ /x/clang12/bin/lldb a.out
(lldb) target create "a.out"
Current executable set to '/x/mess/a.out' (x86_64).
(lldb) log enable -v lldb dyld
(lldb) b main
Breakpoint 1: where = a.out`main + 4 at hello.c:4:3, address =
0x1159
(lldb) run
DynamicLoaderDarwin::UseDYLDSPI: Use old DynamicLoader plugin
DynamicLoaderDarwin::UseDYLDSPI: Use old DynamicLoader plugin
DYLDRendezvous::UpdateExecutablePath exe module executable path set:
'/x/mess/a.out'
DynamicLoaderPOSIXDYLD::DidLaunch()
(section = 0x016E1460 (/x/mess/a.out.PT_LOAD[0]), load_addr =
0x4000) module = 0x0178DE80
(section = 0x01799370 (/x/mess/a.out.PT_LOAD[1]), load_addr =
0x5000) module = 0x0178DE80
(section = 0x0179A370 (/x/mess/a.out.PT_LOAD[2]), load_addr =
0x6000) module = 0x0178DE80
(section = 0x0179A5B0 (/x/mess/a.out.PT_LOAD[3]), load_addr =
0x7e18) module = 0x0178DE80
DynamicLoaderPOSIXDYLD::DidLaunch about to call ProbeEntry()
Rendezvous structure is not set up yet. Trying to locate rendezvous breakpoint
in the interpreter by symbol name.
(section = 0x01803A80 (/usr/lib/x86_64-linux-musl/libc.so.PT_LOAD[0]),
load_addr = 0x77f49000) module = 0x01826080
(section = 0x01803C00 (/usr/lib/x86_64-linux-musl/libc.so.PT_LOAD[1]),
load_addr = 0x77f
[lldb-dev] [Bug 51467] New: LLDB "image list" accumulates duplicate loader+vdso images on restart
https://bugs.llvm.org/show_bug.cgi?id=51467
Bug ID: 51467
Summary: LLDB "image list" accumulates duplicate loader+vdso
images on restart
Product: lldb
Version: unspecified
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
I'm using lldb with a dynamically-linked glibc hello world program:
$ cat hello.c
#include
int main() {
printf("hi\n");
return 0;
}
$ gcc hello.c -g
Each time I restart the program in lldb, "image list" accumulates another copy
of the [vdso] image and the loader image
(/usr/lib/x86_64-linux-gnu/ld-2.31.so):
$ /x/clang12/bin/lldb a.out
(lldb) target create "a.out"
Current executable set to '/x/mess/a.out' (x86_64).
(lldb) image list
[ 0] A57BBE87-FECC-2529-B8F0-06376F8C9954-4C7B7916 0x
/x/mess/a.out
(lldb) b main
Breakpoint 1: where = a.out`main + 4 at hello.c:4:3, address =
0x1139
(lldb) run
Process 639200 launched: '/x/mess/a.out' (x86_64)
Process 639200 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x5139 a.out`main at hello.c:4:3
1#include
2
3int main() {
-> 4 printf("hi\n");
5 return 0;
6}
(lldb) image list
[ 0] A57BBE87-FECC-2529-B8F0-06376F8C9954-4C7B7916 0x4000
/x/mess/a.out
[ 1] 9F75E12B-5CDE-458E-4DDF-E16FC31565F2-C6E3306F 0x77fd2000
/usr/lib/x86_64-linux-gnu/ld-2.31.so
/usr/lib/debug/.build-id/9f/75e12b5cde458e4ddfe16fc31565f2c6e3306f.debug
[ 2] D3D446F7-5BA5-351B-D4C9-2782DF0761ED-0B51B041 0x77fd [vdso]
(0x77fd)
[ 3] FC3F27BB-2B0B-F376-A564-0FA0ECC65A1E-16634CFB 0x77ddc000
/lib/x86_64-linux-gnu/libc.so.6
/usr/lib/debug/.build-id/fc/3f27bb2b0bf376a5640fa0ecc65a1e16634cfb.debug
(lldb) run
There is a running process, kill it and restart?: [Y/n] y
Process 639200 exited with status = 9 (0x0009)
Process 639398 launched: '/x/mess/a.out' (x86_64)
Process 639398 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x5139 a.out`main at hello.c:4:3
1#include
2
3int main() {
-> 4 printf("hi\n");
5 return 0;
6}
(lldb) image list
[ 0] A57BBE87-FECC-2529-B8F0-06376F8C9954-4C7B7916 0x4000
/x/mess/a.out
[ 1] 9F75E12B-5CDE-458E-4DDF-E16FC31565F2-C6E3306F 0x77fd2000
/usr/lib/x86_64-linux-gnu/ld-2.31.so
/usr/lib/debug/.build-id/9f/75e12b5cde458e4ddfe16fc31565f2c6e3306f.debug
[ 2] D3D446F7-5BA5-351B-D4C9-2782DF0761ED-0B51B041 0x77fd [vdso]
(0x77fd)
[ 3] FC3F27BB-2B0B-F376-A564-0FA0ECC65A1E-16634CFB 0x77ddc000
/lib/x86_64-linux-gnu/libc.so.6
/usr/lib/debug/.build-id/fc/3f27bb2b0bf376a5640fa0ecc65a1e16634cfb.debug
[ 4] 9F75E12B-5CDE-458E-4DDF-E16FC31565F2-C6E3306F 0x77fd2000
/usr/lib/x86_64-linux-gnu/ld-2.31.so
/usr/lib/debug/.build-id/9f/75e12b5cde458e4ddfe16fc31565f2c6e3306f.debug
[ 5] D3D446F7-5BA5-351B-D4C9-2782DF0761ED-0B51B041 0x77fd [vdso]
(0x77fd)
(lldb) run
There is a running process, kill it and restart?: [Y/n] y
Process 639398 exited with status = 9 (0x0009)
Process 639416 launched: '/x/mess/a.out' (x86_64)
Process 639416 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x5139 a.out`main at hello.c:4:3
1#include
2
3int main() {
-> 4 printf("hi\n");
5 return 0;
6}
(lldb) image list
[ 0] A57BBE87-FECC-2529-B8F0-06376F8C9954-4C7B7916 0x4000
/x/mess/a.out
[ 1] 9F75E12B-5CDE-458E-4DDF-E16FC31565F2-C6E3306F 0x77fd2000
/usr/lib/x86_64-linux-gnu/ld-2.31.so
/usr/lib/debug/.build-id/9f/75e12b5cde458e4ddfe16fc31565f2c6e3306f.debug
[ 2] D3D446F7-5BA5-351B-D4C9-2782DF0761ED-0B51B041 0x77fd [vdso]
(0x77fd)
[ 3] FC3F27BB-2B0B-F376-A564-0FA0ECC65A1E-16634CFB 0x77ddc000
/lib/x86_64-linux-gnu/libc.so.6
/usr/lib/debug/.build-id/fc/3f27bb2b0bf376a5640fa0ecc65a1e16634cfb.debug
[ 4] 9F75E12B-5CDE-458E-4DDF-E16FC31565F2-C6E3306F 0x77fd2000
/usr/lib/x86_64-linux-gnu/ld-2.31.so
/usr/lib/debug/.build-id/9f/75e12b5cde458e4ddfe16fc31565f2c6e3306f.debug
[ 5] D3D446F7-5BA5-351B-D4C9-2782DF0761ED-0B51B041 [vdso][0x]
[vdso] (0x77fd)
[ 6] 9F75E12B-5CDE-458E-4DDF-E16FC31565F2-C6E3306F 0x77fd2000
/usr/lib/x86_64-linux-gnu/ld-2.31.so
/usr/lib/debug/.build-id/9f/75e12b5cde458e4ddfe16fc31565f2c6e3306f.debug
[ 7] D3D446F7-5BA5-351B-D4C9-2782DF0761ED-0B51B041 0x77fd [vdso]
(0x77fd)
I'll also attached a file with dyld logging enabled.
--
You are receiving this mail because:
Y
