[lldb-dev] [Bug 38312] two errors from unrecognized command
https://bugs.llvm.org/show_bug.cgi?id=38312 Raphael Isemann changed: What|Removed |Added CC||teempe...@gmail.com Assignee|lldb-dev@lists.llvm.org |teempe...@gmail.com -- You are receiving this mail because: You are the assignee for the bug.___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 38317] New: Address breakpoints don't work if set before the process launches
https://bugs.llvm.org/show_bug.cgi?id=38317
Bug ID: 38317
Summary: Address breakpoints don't work if set before the
process launches
Product: lldb
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: ted.woodw...@codeaurora.org
CC: llvm-b...@lists.llvm.org
Setting a breakpoint by address doesn't work if the process isn't running. I
traced it back to r322348, "Fix Breakpoint::RemoveInvalidLocations to fix the
exec testcase.", from January 11.
With ToT from a few days ago on x86_64 Linux, I get the address of main and set
a breakpoint:
(lldb) p main
(int (*)(int, char **)) $0 = 0x00400570
(lldb) b 0x400570
Breakpoint 1: address = 0x00400570
I run, it launches and runs to completion without hitting the breakpoint:
(lldb) r
Process 20293 launched: '/home/ted/lldb_test/factlin' (x86_64) Factorial of 10
is 3628800 Process 20293 exited with status = 0 (0x)
Set a breakpoint by line, launch, and it stops:
(lldb) b 19
Breakpoint 2: where = factlin`main + 22 at factorial.c:32, address =
0x00400586
(lldb) r
Process 20352 launched: '/home/ted/lldb_test/factlin' (x86_64) Process 20352
stopped
* thread #1, name = 'factlin', stop reason = breakpoint 2.1
frame #0: 0x00400586 factlin`main(argc=1, argv=0x7fffe218)
at factorial.c:32
29 }
30 */
31
-> 32 base = 10;
33
34 printf("Factorial of %d is %d\n", base, factorial(base));
35 return 0;
Set the breakpoint by address while the process is running and run again. This
time it stops at the new address breakpoint.
(lldb) b 0x400570
Breakpoint 3: where = factlin`main at factorial.c:13, address =
0x00400570
(lldb) r
There is a running process, kill it and restart?: [Y/n] Process 20352 exited
with status = 9 (0x0009) Process 20366 launched:
'/home/ted/lldb_test/factlin' (x86_64) Process 20366 stopped
* thread #1, name = 'factlin', stop reason = breakpoint 3.1
frame #0: 0x00400570 factlin`main(argc=,
argv=) at factorial.c:13
10 }
11
12 int main(int argc, char **argv)
-> 13 {
14 unsigned base;
15
16 /*
Break list shows the first breakpoint as unresolved, and the third as resolved.
(lldb) br l
Current breakpoints:
1: address = 0x00400570, locations = 1
1.1: address = 0x00400570, unresolved, hit count = 0
2: file = '/home/ted/lldb_test/factorial.c', line = 19, exact_match = 0,
locations = 1, resolved = 1, hit count = 1
2.1: where = factlin`main + 22 at factorial.c:32, address =
0x00400586, resolved, hit count = 1
3: address = factlin[0x00400570], locations = 1, resolved = 1, hit
count = 1
3.1: where = factlin`main at factorial.c:13, address = 0x00400570,
resolved, hit count = 1
--
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Problem with address breakpoints
Hi Jim,
I found a breakpoint problem. Setting a breakpoint by address doesn't work
if the process isn't running. I traced it back to r322348, "Fix
Breakpoint::RemoveInvalidLocations to fix the exec testcase.", from January
11.
With ToT from a few days ago on x86_64 Linux, I get the address of main and
set a breakpoint:
(lldb) p main
(int (*)(int, char **)) $0 = 0x00400570
(lldb) b 0x400570
Breakpoint 1: address = 0x00400570
I run, it launches and runs to completion:
(lldb) r
Process 20293 launched: '/usr2/tedwood/lldb_test/factlin' (x86_64)
Factorial of 10 is 3628800
Process 20293 exited with status = 0 (0x)
Set a breakpoint by line, launch, and it stops:
(lldb) b 19
Breakpoint 2: where = factlin`main + 22 at factorial.c:32, address =
0x00400586
(lldb) r
Process 20352 launched: '/usr2/tedwood/lldb_test/factlin' (x86_64)
Process 20352 stopped
* thread #1, name = 'factlin', stop reason = breakpoint 2.1
frame #0: 0x00400586 factlin`main(argc=1,
argv=0x7fffe218) at factorial.c:32
29 }
30 */
31
-> 32 base = 10;
33
34 printf("Factorial of %d is %d\n", base, factorial(base));
35 return 0;
Set the breakpoint by address while the process is running and run again.
This time it stops at the new address breakpoint.
(lldb) b 0x400570
Breakpoint 3: where = factlin`main at factorial.c:13, address =
0x00400570
(lldb) r
There is a running process, kill it and restart?: [Y/n]
Process 20352 exited with status = 9 (0x0009)
Process 20366 launched: '/usr2/tedwood/lldb_test/factlin' (x86_64)
Process 20366 stopped
* thread #1, name = 'factlin', stop reason = breakpoint 3.1
frame #0: 0x00400570 factlin`main(argc=,
argv=) at factorial.c:13
10 }
11
12 int main(int argc, char **argv)
-> 13 {
14 unsigned base;
15
16 /*
Break list shows the first breakpoint as unresolved, and the third as
resolved.
(lldb) br l
Current breakpoints:
1: address = 0x00400570, locations = 1
1.1: address = 0x00400570, unresolved, hit count = 0
2: file = '/usr2/tedwood/lldb_test/factorial.c', line = 19, exact_match = 0,
locations = 1, resolved = 1, hit count = 1
2.1: where = factlin`main + 22 at factorial.c:32, address =
0x00400586, resolved, hit count = 1
3: address = factlin[0x00400570], locations = 1, resolved = 1, hit
count = 1
3.1: where = factlin`main at factorial.c:13, address = 0x00400570,
resolved, hit count = 1
Ted
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LLDB Demangling
Hello Stefan, thank you for working on this. I believe this work will bring a huge improvement to LLDB. Adding something like DemangleWithRichNameIndexInfo to the Mangled class makes sense to me. However, I don't think that function should be taking an ItaniumPartialDemangler as an argument. The reason for that is that ItaniumPartialDemangler is, unsurprisingly, specific to the itanium mangling scheme, and the Mangled class tries to hide the specifics of different manglings. I would propose to create a new class (RichMangingInfo?), which would wrap both ItaniumPartialDemangler and the existing string-chopping implementation, and provide a unified interface on top of them. Internally it would use IPD for the itanium scheme and the legacy implementation for the MSVC mangling, but the user would not have to care about that, as it can just ask questions like "is this a constructor?" and get the correct answer either way. If ever we get something similar to IPD for the MSVC mangling scheme, we can just replace the legacy implementation with that one, and nobody should know the difference. What do you think? BTW, right now the Symtab class builds a table containing all demangled names. This is mostly unnecessary, and in fact we have recently removed a similar table for the demangled debug_info names. The only present use for it that I am aware of is papering over a clang "bug"*. If we are able to get rid of this, then we might be able to get further speedup by having DemangleWithRichNameIndexInfo *not* fill out the demangled string (as, I understand, building the actual string is the most expensive operation), and just fetching the bits of info we need from the IPD. (*) The "bug" is that sometimes clang will not generate the C1 (full object) flavour of an constructor if it is identical to the C2 version (even though the CU in question definitely constructs full objects of the given class). This means that we are not able able to construct some objects during expression evaluation as we cannot find the C1 version anywhere. The demangling makes this work accidentally, as were are able to match up the constructors by demangled names, as they both demangle to the same string. I have recently fixed clang to emit C1 always (at -O0), but the question remains on what to do with older compilers. On Tue, 24 Jul 2018 at 21:55, Stefan Gränitz wrote: > > Hello everyone > > I am relatively new to the LLDB sources and just submitted my first own > patch for review in Phabricator. Based on this patch I would like to > discuss a few details for further improvements on LLDB's demangling. > > First a short recap on the current state: > * Name demangling used to be a lazy process, exclusively accessible via > Mangled::GetDemangledName() - this is a valuable mechanism: > https://github.com/llvm-mirror/lldb/blob/8ba903256fd92a2d8644b108a7c8a1a15efd90ad/source/Core/Mangled.cpp#L252 > * My patch wants to replace the existing combination of FastDemangle & > itaniumDemangle() with LLVM's new ItaniumPartialDemangler (IPD) > implementation and no fallbacks anymore. It slightly reduces complexity > and slightly improves performance, but doesn't introduce conceptual > changes: https://reviews.llvm.org/D49612 > * IPD provides rich information on names, e.g. isFuntion() or > isCtorOrDtor(), but stores that in its own state rather than returning a > queriable object: > https://github.com/llvm-mirror/llvm/blob/a3de0cbb8f4d886a968d20a8c6a6e8aa01d28c2a/include/llvm/Demangle/Demangle.h#L36 > * IPD's rich info could help LLDB, where it currently parses mangled > names on its own, on-top of demangling. Symtab::InitNameIndexes() seems > to be the most prominent such place. LLDB builds an index with various > categories from all its symbols here. This is performance-critical and > it does not benefit from the laziness in GetDemangledName(): > https://github.com/llvm-mirror/lldb/blob/8ba903256fd92a2d8644b108a7c8a1a15efd90ad/source/Symbol/Symtab.cpp#L218 > > My simple switch doesn't exploit IPD's rich demangling info yet and it > uses a new IPD instance for each demangling request, which is considered > quite costly as it uses a bump allocator internally. Over-all > performance still didn't drop, but even seems to benefit. > > In order to fully exploit the remaining potential, I am thinking about > the following changes: > > (1) In the Mangled class, add a separate entry-point for batch > demangling, that allows to pass in an existing IPD: > bool Mangled::DemangleWithRichNameIndexInfo(ItaniumPartialDemangler ); > > (2) DemangleWithRichNameIndexInfo() will demangle explicitly, which is > required to make sure we gather IPD's rich info. It's not lazy as > GetDemangledName(), but it will store the demangled name and set the > "MangledCounterpart" so that subsequent lazy requests will be fast. > > (3) DemangleWithRichNameIndexInfo() will be used by > Symtab::InitNameIndexes(), which will have a single IPD instance that is > reused for all symbols.
[lldb-dev] [7.0.0 Release] One week to the branch
Hello everyone, Here's just a quick reminder that the upcoming release branch is scheduled for creation one week from today, on Wednesday 1 August 2018. Please try to avoid disruptive changes close to the branch. The full release schedule is available under Upcoming Releases at https://llvm.org/ As the branch is created, the trunk version will become 8.0.0. Cheers, Hans ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
