[Bug 241773] lldb does not display external variables properly.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241773 --- Comment #9 from bc...@lafn.org --- Using (lldb) log enable posix all then run (lldb) p id generates a lot of ptrace entries, however after the p id command, I get: Process 26878 stopped * thread #1, name = 'testprog', stop reason = step in failed (Could not create return address breakpoint. Return address (0x80024d6ae) permissions not found.) frame #0: 0x000800404dd0 libc.so.7`stat libc.so.7`stat: -> 0x800404dd0 <+0>: pushq %rbp 0x800404dd1 <+1>: movq %rsp, %rbp 0x800404dd4 <+4>: pushq %r15 0x800404dd6 <+6>: pushq %r14 (lldb) -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 241773] lldb does not display external variables properly.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241773
--- Comment #8 from bc...@lafn.org ---
Having upgraded to 12.2, I ran the lldb session again. Lldb had degraded
significantly. Stepping through the call to testfunc yields the following:
6
7void testfunc(void);
8int main(int argc, char **argv) {
-> 9testfunc();
10 unknown = 9;
11 printf ("id (%x) = %s\n", (int)&id, id);
12 printf ("sock(%x) = %d\n", (int)&sock, sock);
(lldb) n
Size of testlib.c is 262 bytes.
id (203d74) = aa
sock(203d78) = 5
unknown (203d70) = 9
Process 26735 exited with status = 0 (0x)
lldb no longer stops on the next statement but runs to completion. The output
is correct as always.
Stepping into testfunc works however a print inside testfunc yields the
following:
Process 26847 stopped
* thread #1, name = 'testprog', stop reason = step over
frame #0: 0x00080024d6e2 testlib.so`testfunc at testlib.c:14:53
11stat("testlib.c", &sb);
12strcpy (id, "aa");
13sock = 5;
-> 14printf("Size of testlib.c is %i bytes.\n", (int)sb.st_size);
15 }
16
(lldb) p sock
Program aborted due to an unhandled Error:
Error value was Success. (Note: Success values must still be checked prior to
being destroyed).
Stack dump:
0. Program arguments: lldb testprog
1. HandleCommand(command = "p sock")
#0 0x03b15cae (/usr/bin/lldb+0x3b15cae)
#1 0x03b13f25 (/usr/bin/lldb+0x3b13f25)
#2 0x03b165b0 (/usr/bin/lldb+0x3b165b0)
#3 0x0008046c9b70 (/lib/libthr.so.3+0x14b70)
Abort (core dumped)
Basically, 12.2 lldb is not suitable for development work. It looks like I am
going to have to revert back to 12.1.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 241137] Base lldb 9 crashes compared to devel/llvm90
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241137 Dimitry Andric changed: What|Removed |Added Status|New |Closed Resolution|--- |FIXED CC||d...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 241773] lldb does not display external variables properly.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241773 --- Comment #7 from Ed Maste --- You can turn on logging in lldb to help figure out what is going on - sorry it has been some time since I've been actively involved in lldb and do not recall the specific channels and categories. To see all of the channels and categories: (lldb) log list For example, run (lldb) log enable posix all then run (lldb) p id -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 241137] Base lldb 9 crashes compared to devel/llvm90
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241137 --- Comment #4 from Ed Maste --- I think this is resolved now? -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 241773] lldb does not display external variables properly.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241773
--- Comment #6 from Ed Maste ---
Tried to reproduce on -current with
lldb version 11.0.0 (g...@github.com:llvm/llvm-project.git revision
llvmorg-11.0.0-rc2-0-g414f32a9e86)
clang revision llvmorg-11.0.0-rc2-0-g414f32a9e86
llvm revision llvmorg-11.0.0-rc2-0-g414f32a9e86
$ make
rm -f testlib.o testlib.so testprog
cc -Wall -g -c -fPIC -o testlib.o testlib.c
cc -shared -Wl,-export-dynamic -o testlib.so testlib.o
cc -Wall -g -o testprog ./testlib.so testprog.c
./testprog
sock = 5, id = aa
Size of testlib.c is 311 bytes.
id = aa
sock = 5
$ lldb ./testprog
(lldb) target create "./testprog"
Current executable set to '/home/emaste/bugs/pr241773/testprog' (x86_64).
(lldb) b main
Breakpoint 1: where = testprog`main + 22 at testprog.c:8:2, address =
0x00201976
(lldb) run
Process 2340 launching
Process 2340 launched: '/home/emaste/bugs/pr241773/testprog' (x86_64)
Process 2340 stopped
* thread #1, name = 'testprog', stop reason = breakpoint 1.1
frame #0: 0x00201976 testprog`main(argc=1, argv=0x7fffe720)
at testprog.c:8:2
5
6void testfunc(void);
7int main(int argc, char **argv) {
-> 8 testfunc();
9 printf ("id = %s\n", id);
10printf ("sock = %d\n", sock);
11return 0;
(lldb) n
sock = 5, id = aa
Size of testlib.c is 311 bytes.
Process 2340 stopped
* thread #1, name = 'testprog', stop reason = step over
frame #0: 0x0020197b testprog`main(argc=1, argv=0x7fffe720)
at testprog.c:9:2
6void testfunc(void);
7int main(int argc, char **argv) {
8 testfunc();
-> 9 printf ("id = %s\n", id);
10printf ("sock = %d\n", sock);
11return 0;
12 }
(lldb) p id
(char [4]) $0 = ""
(lldb) p sock
(int) $1 = 0
(lldb) c
id = aa
sock = 5
Process 2340 resuming
Process 2340 exited with status = 0 (0x)
(lldb) ^D
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 250702] c++filt crashes on a symbol representing a C++ lambda function
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250702 --- Comment #15 from Ed Maste --- (In reply to Dimitry Andric from comment #14) > That said, it might be more future-proof if we import libcxxabi from > the llvm project into contrib, and start building that, at least > for its demangler support. Indeed, I've thought about doing that at least for c++filt even if we don't use it for the C++ runtime. We already have a copy of the libcxxabi demangler being used in lldb. That said it's still worth fixing as many of the elftc demangler issues as we can. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 250783] ld segmentation fault
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250783 --- Comment #6 from Dimitry Andric --- Ok, to have something to submit to upstream, we need a reproduction case, and lld has an option for this, which produces a tarball: --reproduce= Write a tar file containing input files and command line options to reproduce link So can you repeat the link operation you did on your FreeBSD 13.0 VM with lld 11.0.0, and add an additional flag to the "linking with cc" line, e.g.: -Wl,--reproduce=bug250783.tar If you re-run the link, it should produce a bug250783.tar file with everything in it to be able reproduce the failure. Please compress this with xz and attach it here. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 250388] unable to make buildworld releng/12.1. clang always crashes
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250388 --- Comment #8 from Alex Richardson --- I believe that backporting this change is very low risk. However it depends on a previous commits being merged too. I do not currently have a setup to do this backporting, but if someone else would like to backport 366850 + 367101 (and possibly 366851) please go ahead. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 250702] c++filt crashes on a symbol representing a C++ lambda function
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250702 --- Comment #14 from Dimitry Andric --- (In reply to Yuri Victorovich from comment #13) Yes, the elftoolchain demangler misses a few more modern features, and its development does not seem very active. (Not necessarily for the other parts of elftoolchain such as libelf, btw.) That said, with the fixes I've proposed for upstream, only the lambda examples don't demangle correctly, but the rest does. E.g. I now get: _ZZ5func1vENK3$_0clEv -> func1()::$_0::operator()() const _ZZN7WebCore19SVGAnimatedProperty20LookupOrCreateHelperINS_32SVGAnimatedStaticPropertyTearOffIbEEbLb1EE21lookupOrCreateWrapperEPNS_10SVGElementEPKNS_15SVGPropertyInfoERbE19__PRETTY_FUNCTION__ -> WebCore::SVGAnimatedProperty::LookupOrCreateHelper, bool, true>::lookupOrCreateWrapper(WebCore::SVGElement*, WebCore::SVGPropertyInfo const*, bool&)::__PRETTY_FUNCTION__ _ZNSt3__116__copy_unalignedINS_6vectorIbNS_9allocatorIbLb0EEENS_14__bit_iteratorIT_Lb0EXLi0NS5_IS6_XT0_EXLi0S8_S7_ -> std::__1::__bit_iterator std::__1::__copy_unaligned >, false>(std::__1::__bit_iterator, 0>, std::__1::__bit_iterator, 0>, std::__1::__bit_iterator) _ZZN10half_float6detail15half2float_implEjfNSt3__117integral_constantIbLb114exponent_table -> half_float::detail::half2float_impl(unsigned int, float, std::__1::integral_constant)::exponent_table So the remaining one is: _ZZN9libunwind17LocalAddressSpace18findUnwindSectionsEjRNS_18UnwindInfoSectionsEENUlP12dl_phdr_infojPvE_8__invokeES4_jS5_ That said, it might be more future-proof if we import libcxxabi from the llvm project into contrib, and start building that, at least for its demangler support. At some point it might even replace libcxxrt, or serve as a drop-in replacement. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
