| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In an effort to make Process more language agnostic, I removed
GetCPPLanguageRuntime from Process. I'm following up now with an equivalent
change for ObjC.
Differential Revision: https://reviews.llvm.org/D63052
llvm-svn: 362981
|
|
|
|
|
|
|
| |
Reflow the text for the table to make the table legible. This is purely
cosmetic, but makes understanding the contents of the table easier. NFCI.
llvm-svn: 362961
|
|
|
|
| |
llvm-svn: 362960
|
|
|
|
|
|
|
|
|
|
| |
Ensure that errors are passed through correctly when performing
register read/write operations. Currently, any ptrace() errors are
silently discarded and LLDB behaves as if operation was successful.
Differential Revision: https://reviews.llvm.org/D63054
llvm-svn: 362946
|
|
|
|
|
|
|
| |
I forgot to remove this when I removed GetCPPLanguageRuntime from
Process
llvm-svn: 362885
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Using llvm-style rtti gives us stronger guarantees around casting
LanguageRuntimes.
As discussed in D62755
Differential Revision: https://reviews.llvm.org/D62934
llvm-svn: 362884
|
|
|
|
|
|
|
|
|
| |
This reverts commit 58afc1bdebf9fa8b178d6c9d89af94c5cc091760.
This commit caused the test suite on macOS to fail many tests. It
appears that setting breakpoints is the issue. One example that fails
is the lit test Breakpoint/case-sensitive.test.
llvm-svn: 362862
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem discovered in the breakpoint lit test, but probably exists in others.
lldb-test splits lines on LF. Input files that are CR+LF separated (as is
common on Windows) then resulted in commands being sent to LLDB that ended
in CR, which confused the command interpreter.
This could be fixed at different levels:
1. Treat '\r' like a tab or space in the argument splitter.
2. Fix the line splitters (plural) in lldb-test.
3. Normalize the test files to LF only.
If we did only 3, I'd expect similar problems to recur, so this patch does
1 and 2. I may also do 3 in a separate patch later, but that's tricky
because I believe we have some input files that MUST use CR+LF.
Differential Revision: https://reviews.llvm.org/D62759
llvm-svn: 362844
|
|
|
|
|
|
|
|
| |
lldb/lit/SymbolFile/DWARF/debug-types-expressions.test fails with msan.
This change fixes the issue by ensuring FileNameEntry::checksum is
always default-initialized.
llvm-svn: 362843
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The DWARFCompileUnit is set as the "user data" of the lldb compile unit
directly in the constructor (see ParseCompileUnit).
This means that instead of going through unit indexes, we can just fetch
the DWARF unit directly from there.
Reviewers: clayborg, JDevlieghere
Subscribers: aprantl, jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D62943
llvm-svn: 362783
|
|
|
|
| |
llvm-svn: 362639
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Once we've attached to the process we load all current modules and also set a breakpoint at the rendezvous break address.
However, we don't do this if we already have a load address for the image info address (e.g.: DT_DEBUG on ELF). This code was added 4 years ago when adding support for `$qXfer:Libraries:` packet (https://reviews.llvm.org/D9471) but its intention is not 100% clear to me. It seems to me we're using that check to know if the modules have already been loaded (which they have if `$qXfer:Libraries:` is supported by the gdb server) and skip loading the modules again in the following `if` block. The problem is that we also skip setting the Rendezvous breakpoint so we stop knowing when the process loads new modules.
I fix this by moving the call to set the breakpoint to the end of the function so we always call it as long as we have a valid executable.
Reviewers: ADodds, clayborg, eugene, labath
Reviewed By: eugene, labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D62168
llvm-svn: 362619
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
r362103 exposed a bug, where we could read incorrect data if a skeleton
unit contained more than the single unit DIE. Clang emits these kinds of
units with -fsplit-dwarf-inlining (which is also the default).
Changing lldb to handle these DIEs is nontrivial, as we'd have to change
the UID encoding logic to be able to reference these DIEs, and fix up
various places which are assuming that all DIEs come from the separate
compile unit.
However, it turns out this is not necessary, as the DWO unit contains
all the information that the skeleton unit does. So, this patch just
skips parsing the extra DIEs if we have successfully found the DWO file.
This enforces the invariant that the rest of the code is already
operating under.
This patch fixes a couple of existing tests, but I've also included a
simpler test which does not depend on execution of binaries, and would
have helped us in catching this sooner.
Reviewers: clayborg, JDevlieghere, aprantl
Subscribers: probinson, dblaikie, lldb-commits
Differential Revision: https://reviews.llvm.org/D62852
llvm-svn: 362586
|
|
|
|
| |
llvm-svn: 362570
|
|
|
|
| |
llvm-svn: 362557
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
I want to remove this method because I think that Process should be
language agnostic, or at least, not have knowledge about specific language
runtimes. There is "GetLanguageRuntime()" which should be used instead. If the
caller a CPPLanguageRuntime, they should cast it as needed. Ideally, this
should only happen in plugins that need C++ specific knowledge.
The next step I would like to do is remove "GetObjCLanguageRuntime()" as well.
There are a lot more instances of that function being used, so I wanted to
upload this one first to get the general reception to this idea.
Reviewers: compnerd, davide, JDevlieghere, jingham, clayborg, labath, aprantl
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D62755
llvm-svn: 362544
|
|
|
|
|
|
|
|
|
|
| |
Add a function to flatten the nested aggregate type
Differential Revision: https://reviews.llvm.org/D62702
Patch by Wanyi Ye <kusmour@gmail.com>
llvm-svn: 362543
|
|
|
|
|
|
|
|
| |
"Add support for mid-function epilogues on x86 that end in a non-local jump."
Detected by asan.
llvm-svn: 362510
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
SymbolsDidLoad is currently only implemented for ObjCLanguageRuntime,
but that doesn't mean that it couldn't be useful for other Langauges. Although
this change seems like it's generalizing for the sake of purity, this removes
Target's dependency on ObjCLanguageRuntime.
Differential Revision: https://reviews.llvm.org/D62796
llvm-svn: 362461
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
LookupRuntimeSymbol seems like a general LanguageRuntime method.
Although no other language runtime currently implements this, there's no
reason another language runtime couldn't use this.
Additionally, this breaks IRExecutionUnit's dependency on
ObjCLanguageRuntime.
Reviewers: compnerd, labath, JDevlieghere, davide
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D62795
llvm-svn: 362458
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The x86 assembly inspection engine has code to support detecting a
mid-function epilogue that ends in a RET instruction; add support for
recognizing an epilogue that ends in a JMP, and add a check that the
unwind state has been restored to the original stack setup; reinstate
the post-prologue unwind state after this JMP instruction.
The assembly inspection engine used for other architectures,
UnwindAssemblyInstEmulation, detects mid-function epilogues by
tracking branch instructions within the function and "forwards"
the current unwind state to the targets of the branches. If
an epilogue unwinds the stack and exits, followed by a branch
target, we get back to the correct unwind state. The x86
unwinder should move to this same algorithm, or possibly even
look at implementing an x86 instruction emulation plugin and
get UnwindAssemblyInstEmulation to work for x86 too. I added
a branch instruction recognizier method that will be necessary
if we want to switch the algorithm.
Differential Revision: https://reviews.llvm.org/D62764
<rdar://problem/51074422>
llvm-svn: 362456
|
|
|
|
|
|
|
|
|
| |
Change rL362280 changed CodeView API getRegisterNames() by adding an input
parameter in CPUType. It is called in LLDB and needs to be updated.
Differential Revision: https://reviews.llvm.org/D62772
llvm-svn: 362349
|
|
|
|
| |
llvm-svn: 362339
|
|
|
|
| |
llvm-svn: 362318
|
|
|
|
| |
llvm-svn: 362306
|
|
|
|
| |
llvm-svn: 362268
|
|
|
|
| |
llvm-svn: 362259
|
|
|
|
|
|
|
|
|
| |
This patch makes the FormatEntity honor the debugger's color settings by
not inserting ASCII escape sequences when colors are disabled.
Differential revision: https://reviews.llvm.org/D62714
llvm-svn: 362240
|
|
|
|
|
|
|
| |
The string returned only sometimes ends in NULL. Explicitly check for the NULL
and pop off the NULL if it is there.
llvm-svn: 362194
|
|
|
|
|
|
|
| |
The created string is one char too large, so it pulls the terminating NULL as
the last character of the string. This later causes SocketTest.cpp to fail.
llvm-svn: 362192
|
|
|
|
|
|
|
|
|
|
| |
There is likely also an underlying bug in all code that calls
CPlusPlusNameParser with nullptrs, but this patch can also stand for
itself.
rdar://problem/49072829
llvm-svn: 362177
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
My main goal here is to make lldb-server work with Android Studio.
This is currently not the case because lldb-server is started in platform mode listening on a domain socket. When Android Studio connects to it lldb-server crashes because even though it's listening on a domain socket as soon as it gets a connection it asserts that it's a TCP connection, which will obviously fails for any non-tcp connection.
To do this I came up with a new method called GetConnectURI() in Socket that returns the URI needed to connect to the connected portion of the socket.
Reviewers: labath, clayborg, xiaobai
Reviewed By: labath
Subscribers: mgorny, jfb, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D62089
llvm-svn: 362173
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When creating a ThreadPlan to step through a trampoline, we ask the
ObjC language runtime and the CPP language runtime to come up with such a thread
plan if the dynamic loader fails to give us one. I don't see why this behavior
can't be language agnostic.
Differential Revision: https://reviews.llvm.org/D61921
llvm-svn: 362164
|
|
|
|
| |
llvm-svn: 362154
|
|
|
|
|
|
|
|
|
| |
Changes:
- update comments to detail the info can come from .debug_info or .debug_types
- Rename "debug_info_data" to "data" now that we can get data from .debug_info or .debug_types.
- Also call DWARFDebugInfoEntry::GetAbbreviationDeclarationPtr(...) instead of manually grabbing abbreviation.
llvm-svn: 362116
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The issue was caused by the error checking code that was added. It was incorrectly adding an extra abbreviation when DWARFEnumState::Complete was received since it would push an extra abbreviation onto the list with the abbreviation code of zero. This cause m_idx_offset in each DWARFAbbreviationDeclarationSet to be set to UINT32_MAX. This valid indicates we must linearly search for attributes, not access them in O(1) time. This caused every DWARFDebugInfoEntry that would try to get its DWARFAbbreviationDeclaration from the CU's DWARFAbbreviationDeclarationSet to always linearly search the abbreviation set for a given abbreviation code. Easy to see why this would cause things to be slow.
This regression was caused by: https://reviews.llvm.org/D59370. I asked to ensure there was no regression is parsing or access speed, but that must not have been done. In my test with 40 DWARF files trying to set a breakpoint by function name and in a header file, I see a 8% speed improvement with this fix.
There was no regression in correctness, just very inefficient access.
Added full unit testing for DWARFAbbreviationDeclarationSet parsing to ensure this doesn't regress.
Differential Revision: https://reviews.llvm.org/D62630
llvm-svn: 362105
|
|
|
|
|
|
|
|
|
|
| |
When LLDB first started we didn't have our mmap of the DWARF data done correctly and if the backing file would change we would get live changes as the file changed and it would cause problems. We now mmap correctly and do not run into these issues. There was legacy code in DWARFDebugInfoEntry::GetAbbreviationDeclarationPtr(...) that would always extract the abbrev index each time the function was called to verify that DWARF data hadn't changed and a warning was emitted if it did. We no longer need this and the code was removed. The other thing this function did when it parsed the abbrev index was give us the offset of the first attribute bytes by adding the LEB128 size to the offset. This required an extra parameter to DWARFDebugInfoEntry::GetAbbreviationDeclarationPtr(...) which is now removed. I added "lldb::offset_t DWARFDebugInfoEntry::GetFirstAttributeOffset() const" which calculates this when we need it and modified all sites that need the offset to call it.
Now that we aren't decoding and verifying the abbrev index, it speeds up DWARF access by 1% to 2%.
Differential Revision: https://reviews.llvm.org/D62634
llvm-svn: 362103
|
|
|
|
|
|
|
| |
This removes places where DW_AT_decl_file/line/column was being parsed,
but not used.
llvm-svn: 362086
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The ParseTypeFromDWARF function consists of a huge switch on the kind of
type being parsed. Each case in this switch starts with parsing the
attributes of the current DIE. A lot of these attributes are specific to
one kind of a type, but a lot of them are common too, leading to code
duplication.
This patch reduces the duplication (and the size of ParseTypeFromDWARF)
by moving the attribute parsing to a separate function. It creates a
struct (ParsedTypeAttributes), which contains a parsed form of all
attributes which are useful for parsing any kind of a type. The parsing
code for a specific type kind can then access the fields which are
relevant for that specific case.
Reviewers: JDevlieghere, clayborg, aprantl
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D62477
llvm-svn: 362075
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's no reason for anyone to modify a list from outside of a symbol
file (as that would break a lot of invariants that symbol files depend
on).
Make the function return a const FileSpecList and fix up a couple of
places that were needlessly binding non-const references to the result
of this function.
llvm-svn: 362069
|
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D62221
Patch by Guilherme Andrade <guiandrade@google.com>.
llvm-svn: 362063
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Extract()
The function Extract() is almost a duplicate of FastExtract() but is not used.
Delete it and rename FastExtract() to Extract().
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D62593
llvm-svn: 362049
|
|
|
|
| |
llvm-svn: 362042
|
|
|
|
| |
llvm-svn: 362035
|
|
|
|
| |
llvm-svn: 362032
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Currently there's not really a good way to iterate over the language runtimes a
process has. This is sometimes desirable (as seen in my change to Thread).
Additionally, there's not really a good reason to iterate over every available
language, but rather only over languages for which we have a plugin loaded.
Reviewers: JDevlieghere, davide, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D62562
llvm-svn: 361999
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The `log timer dump` is showing the time of the function itself minus any function that is called from this one that also happens to be timed. However, this is really not obvious and it also makes it hard to understand the time spent in total and also which children are actually taking the time.
To get a better reading of the timer dump I added the total, children (which I named child) and also the hit count. I used these timers to figure out a performance issue and only after adding this things were more clear to me.
It looks like this:
```
(lldb) log timer dump
35.447713617 sec (total: 35.449s; child: 0.001s; count: 1374) for void SymbolFileDWARF::Index()
29.717921481 sec (total: 29.718s; child: 0.000s; count: 8230500) for const lldb_private::ConstString &lldb_private::Mangled::GetDemangledName(lldb::LanguageType) const
21.049508865 sec (total: 24.683s; child: 3.633s; count: 1399) for void lldb_private::Symtab::InitNameIndexes()
...
```
Reviewers: clayborg, teemperor, labath, espindola, xiaobai
Reviewed By: labath, xiaobai
Subscribers: emaste, mgorny, arichardson, eraman, MaskRay, jdoerfert, labath, davide, teemperor, aprantl, erik.pilkington, jfb, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D61235
llvm-svn: 361987
|
|
|
|
| |
llvm-svn: 361962
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This code is modifying a support file list after it has been created.
This makes it hard to share the file list between type units and
compile units in DWARF. It's not a total showstopper, but supporting
this while also sharing the lists would make things more complicated.
Given that this was added to support a project which never fully
materialised, and that even back then there were some concerns about the
correctness of this approach (according to D11003#200772 the compile
unit name is not guaranteed to be the first one in the support file
list), I think we should just delete this workaround.
Reviewers: clayborg, tberghammer, dsrbecky
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D62517
llvm-svn: 361948
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The function was not being consistent in how it retrieved the language
of the current compile unit. Sometimes it did so from the lldb CU
object, and sometimes from the DWARF die. This patch unifies the
handling on the latter. The reason for choosing the DWARF method is
because I'd eventually like to stop creating lldb CUs for dwarf type
units (and so this code needs to would need to work without them).
Reviewers: clayborg, JDevlieghere, aprantl
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D62481
llvm-svn: 361939
|