| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
Patch by Ali Tamur! (tamur@google.com)
llvm-svn: 351158
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This parameter was only ever used with the Module set, and
since a SymbolFile is tied to a module, the parameter turns
out to be entirely unnecessary. Furthermore, it doesn't make
a lot of sense to ask a caller to ask SymbolFile which is tied
to Module X to find types for Module Y, but that possibility
was open with the previous interface. By removing this
parameter from the API, it makes it harder to use incorrectly
as well as easier for an implementor to understand what it
needs to do.
llvm-svn: 351133
|
|
|
|
|
|
|
|
|
|
|
| |
Every callsite was passing an empty SymbolContext, so this parameter
had no effect. Inside the DWARF implementation of this function,
however, there was one codepath that checked members of the
SymbolContext. Since no call-sites actually ever used this
functionality, it was essentially dead code, so I've deleted this
code path as well.
llvm-svn: 351132
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This method took a SymbolContext but only actually cared about the
case where the m_function member was set. Furthermore, it was
intended to be implemented to parse blocks recursively despite not
documenting this in its name. So we change the name to indicate
that it should be recursive, while also limiting the function
parameter to be a Function&. This lets the caller know what is
required to use it, as well as letting new implementers know what
kind of inputs they need to be prepared to handle.
llvm-svn: 351131
|
|
|
|
|
|
|
| |
The addition of SymbolFileBreakpad crossed paths with my change,
so this interface needs to be fixed up as well.
llvm-svn: 350950
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously all of these functions accepted a SymbolContext&.
While a CompileUnit is one member of a SymbolContext, there
are also many others, and by passing such a monolithic parameter
in this way it makes the requirements and assumptions of the
API unclear for both callers as well as implementors.
All these methods need is a CompileUnit. By limiting the
parameter type in this way, we simplify the code as well as
make it self-documenting for both implementers and users.
Differential Revision: https://reviews.llvm.org/D56564
llvm-svn: 350943
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This commit adds the glue code necessary to integrate the
SymbolFileBreakpad into the plugin system. Most of the methods are
stubbed out. The only method implemented method is AddSymbols, which
parses the PUBLIC "section" of the breakpad "object file", and fills out
the Module's symtab.
To enable testing this, I've made two additional changes:
- dump Symtab from the SymbolVendor class. The symtab was already being
dumped as a part of the object file dump, but that happened before
symbol vendor kicked in, so it did not reflect any symbols added
there.
- add ability to explicitly specify the external symbol file in
lldb-test (so that the object file could be linked with the breakpad
symbol file). To make things simpler, I've changed lldb-test from
consuming multiple inputs (and dumping their symbols) to having it
just process a single file per invocation. This was not a problem
since everyone was using it that way already.
Reviewers: clayborg, zturner, lemo, markmentovai, amccarth
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D56173
llvm-svn: 350924
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code was assuming that the elf file will have a PT_LOAD segment
starting from the first byte of the file. While this is true for files
generated by most linkers (it's a way of saving space), it is not a
requirement. And files not satisfying this constraint can still be
perfectly executable. yaml2obj is one of the tools which produces files
like this.
This patch relaxes the check in ObjectFileELF to take the address of the
first PT_LOAD segment as the base address of the object (instead of the
one with the offset 0). Since the PT_LOAD segments are supposed to be
sorted according to the VM address, this entry will also be the one with
the lowest VM address.
If we ever run into files which don't have the PT_LOAD segments sorted,
we can easily change this code to return the lowest VM address as the
base address (if that is the correct thing to do for these files).
llvm-svn: 350923
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The function SymbolFile::ParseTypes previously accepted a SymbolContext.
This makes it extremely difficult to implement faithfully, because you
have to account for all possible combinations of members being set in
the SymbolContext. On the other hand, no clients of this function
actually care about implementing this function to this strict of a
standard. AFAICT, there is actually only 1 client in the entire
codebase, and it is the function ParseAllDebugSymbols, which is itself
only called for testing purposes when dumping information. At this
call-site, the only field it sets is the CompileUnit, meaning that an
implementer of a SymbolFile need not worry about any examining or
handling any other fields which might be set.
By restricting this API to accept exactly a CompileUnit& and nothing
more, we can simplify the life of new SymbolFile plugin implementers by
making it clear exactly what the necessary and sufficient set of
functionality they need to implement is, while at the same time removing
some dead code that tried to handle other types of SymbolContext fields
that were never going to be set anyway.
Differential Revision: https://reviews.llvm.org/D56462
llvm-svn: 350889
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Typedefs are represented as S_UDT records in the globals stream. This
creates a strange situation where "types" are actually represented as
"symbols", so they need special handling.
In order to test this, we don't just use lldb and print out some
variables causing the AST to get created, because variables whose type
is a typedef will have debug info referencing the original type, not the
typedef. So we use lldb-test instead which will parse all debug info in
the entire file. This exposed some problems with lldb-test and the
native reader, mainly that certain types of obscure symbols which we can
find when iterating every single record would trigger crashes. These
have been fixed as well so that lldb-test can be used to test this
functionality.
Differential Revision: https://reviews.llvm.org/D56461
llvm-svn: 350888
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a section name is exactly 8 bytes long (or has been truncated to 8
bytes), it will not contain the terminating nul character. This means
reading the name as a c string will pick up random data following the
name field (which happens to be the section vm size).
This fixes the name computation to avoid out-of-bounds access and adds a
test.
Reviewers: zturner, stella.stamenova
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D56124
llvm-svn: 350809
|
|
|
|
|
|
|
|
|
| |
Summary:
The concept of a base address was already present in the implementation
(it's needed for computing section load addresses properly), but it was
never exposed through this function. This fixes that.
llvm-svn: 350804
|
|
|
|
|
|
|
|
|
|
| |
was working on something else.
DynamicLoaderDarwinKernel::SearchForKernelNearPC should have had
an early return if the pc value is not in high memory; add that.
The search for a kernel at 0x2000 offsets was a stopgap; it doesn't
need to be checked any longer.
llvm-svn: 350786
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This adds unnamed pipe support in PipeWindows to support communication between a debug server and child process.
Modify PipeWindows::CreateNew to support the creation of an unnamed pipe.
Rename the previous method that created a named pipe to PipeWindows::CreateNewNamed.
Reviewers: zturner, llvm-commits
Reviewed By: zturner
Subscribers: Hui, labath, lldb-commits
Differential Revision: https://reviews.llvm.org/D56234
llvm-svn: 350784
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ParseDeclsForContext was originally created to serve the very specific
case where the context is a function block. It was never intended to be
used for arbitrary DeclContexts, however due to the generic name, the
DWARF and PDB plugins implemented it in this way "just in case". Then,
lldb-test came along and decided to use it in that way.
Related to this, there are a set of functions in the SymbolFile class
interface whose requirements and expectations are not documented. For
example, if you call ParseCompileUnitFunctions, there's an inherent
requirement that you create entries in the underlying clang AST for
these functions as well as their signature types, because in order to
create an lldb_private::Function object, you have to pass it a
CompilerType for the parameter representing the signature.
On the other hand, there is no similar requirement (either inherent or
documented) if one were to call ParseDeclsForContext. Specifically, if
one calls ParseDeclsForContext, and some variable declarations, types,
and other things are added to the clang AST, is it necessary to create
lldb::Variable, lldb::Type, etc objects representing them? Nobody knows.
There is, however, an accidental requirement, because since all of the
plugins implemented this just in case, lldb-test came along and used
ParsedDeclsForContext, and then wrote check lines that depended on this.
When I went to try and implemented the NativePDB reader, I did not
adhere to this (in fact, from a layering perspective I went out of my
way to avoid it), and as a result the existing DIA PDB tests don't work
when the native PDB reader is enabled, because they expect that calling
ParseDeclsForContext will modify the *module's* view of symbols, and not
just the internal AST.
All of this confusion, however, can be avoided if we simply stick to
using ParseDeclsForContext for its original intended use case (blocks),
and use a different function (ParseAllDebugSymbols) for its intended use
case which is, unsuprisingly, to parse all the debug symbols (which is
all lldb-test really wanted to do anyway).
In the future, I would like to change ParseDeclsForContext to
ParseDeclsForFunctionBlock, then delete all of the dead code inside that
handles other types of DeclContexts (and probably even assert if the
DeclContext is anything other than a block).
A few PDB tests needed to be fixed up as a result of this, and this also
exposed a couple of bugs in the DIA PDB reader (doesn't matter much
since it should be going away soon, but worth mentioning) where the
appropriate AST entries weren't being created always.
Differential Revision: https://reviews.llvm.org/D56418
llvm-svn: 350764
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is the result of the discussion in D55356, where it was suggested
as a solution to representing the addresses that logically belong to a
module in memory, but are not a part of any of its sections.
The ELF PT_LOAD segments are similar to the MachO "load commands",
except that the relationship between them and the object file sections
is a bit weaker. While in the MachO case, the sections belonging to a
specific segment are placed directly inside it in the object file
logical structur, in the ELF case, the sections and segments form two
separate hierarchies. This means that it is in theory possible to create
an elf file where only a part of a section would belong to some segment
(and another part to a different one). However, I am not aware of any
tool which would produce such a file (and most tools will have problems
ingesting them), so this means it is still possible to follow the MachO
model and make sections children of the PT_LOAD segments.
In case we run into (corrupt?) files with overlapping sections, I have
added code (and tests) which adjusts the sizes and/or drops the offending
sections in order to present a reasonable image to the upper layers of
LLDB. This is mostly done for completeness, as I don't anticipate
running into this situation in the real world. However, if we do run
into it, and the current behavior is not suitable for some reason, we
can implement this logic differently.
Reviewers: clayborg, jankratochvil, krytarowski, joerg, espindola
Subscribers: emaste, arichardson, lldb-commits
Differential Revision: https://reviews.llvm.org/D55998
llvm-svn: 350742
|
|
|
|
|
|
|
|
|
|
| |
LLVM added wrappers to std::sort (r327219) that randomly shuffle the
container before sorting. The goal is to uncover non-determinism due to
undefined sorting order of objects having the same key.
This can be enabled with -DLLVM_ENABLE_EXPENSIVE_CHECKS=ON.
llvm-svn: 350679
|
|
|
|
|
|
|
|
|
|
| |
Summary: The member is private and unused if HAVE_LIBCOMPRESSION is undefined, which triggers Clang's -Wunused-private-field warning.
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D56458
llvm-svn: 350675
|
|
|
|
|
|
|
| |
PdbAstBuilder.cpp:273:20: warning: unused function 'GetParentUniqueName' [-Wunused-function]
PdbAstBuilder.cpp:267:13: warning: unused function 'IsUniqueNameEnumTag' [-Wunused-function]
llvm-svn: 350652
|
|
|
|
| |
llvm-svn: 350651
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The target was being used in FinalizeFileActions to provide default
values for stdin/out/err. Also, most of the logic of this function was
very specific to how the lldb's Target class wants to launch processes,
so I, move it to Target::FinalizeFileActions, inverting the dependency.
The only piece of logic that was useful elsewhere (lldb-server) was the
part which sets up a pty and relevant file actions. I've kept this part
as ProcessLaunchInfo::SetUpPtyRedirection.
This makes ProcessLaunchInfo independent of any high-level lldb constructs.
Reviewers: zturner, jingham, teemperor
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D56196
llvm-svn: 350617
|
|
|
|
| |
llvm-svn: 350577
|
|
|
|
| |
llvm-svn: 350576
|
|
|
|
|
|
| |
Despite the name, this function has nothing to do with the DWO format.
llvm-svn: 350575
|
|
|
|
| |
llvm-svn: 350570
|
|
|
|
|
|
|
|
| |
If the minidump contains a saved exception record use it automatically.
Differential Revision: https://reviews.llvm.org/D56293
llvm-svn: 350546
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch allows ObjectFileBreakpad to parse the contents of Breakpad
files into sections. This sounds slightly odd at first, but in essence
its not too different from how other object files handle things. For
example in elf files, the symtab section consists of a number of
"records", where each record represents a single symbol. The same is
true for breakpad's PUBLIC section, except in this case, the records will be
textual instead of binary.
To keep sections contiguous, I create a new section every time record
type changes. Normally, the breakpad processor will group all records of
the same type in one block, but the format allows them to be intermixed,
so in general, the "object file" may contain multiple sections with the
same record type.
Reviewers: clayborg, zturner, lemo, markmentovai, amccarth
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D55434
llvm-svn: 350511
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The Debuffer object was being used in "GetListenerForProcess" to provide
a default listener object if one was not specified in the launch_info
object.
Since all the callers of this function immediately passed the result to
Target::CreateProcess, it was easy to move this logic there instead.
This brings us one step closer towards being able to move the LaunchInfo
classes to the Host layer (which is there the launching code that
consumes them lives).
Reviewers: zturner, jingham, teemperor
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D56174
llvm-svn: 350510
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The main difference between the classes was supposed to be the fact that
one is backed by llvm::SmallVector, and the other by std::vector.
However, over the years, they have accumulated various other differences
too.
This essentially removes the std::vector version, as that is pretty much
identical to llvm::SmallVector<T, 0>, and combines their interfaces. It
does not attempt to do a more significant refactoring, even though there
is still a lot of duplication in this file, as it is hard to tell which
quirk of some API is depended on by somebody (and, a previous, more
ambitious attempt at this in D16769 has failed).
I also add some tests, including one which demonstrates one of the
quirks/bugs of the API I have noticed in the process.
Reviewers: clayborg, teemperor, tberghammer
Subscribers: mgorny, JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D56170
llvm-svn: 350380
|
|
|
|
|
|
|
|
| |
recognized arguments
Differential Revision: https://reviews.llvm.org/D56027
llvm-svn: 350376
|
|
|
|
|
|
|
|
| |
GetExceptionObjectForThread
Differential Revision: https://reviews.llvm.org/D56115
llvm-svn: 350375
|
|
|
|
| |
llvm-svn: 350298
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
instead of returning the architecture through by-ref argument and a
boolean value indicating success, we can just return the ArchSpec
directly. Since the ArchSpec already has an invalid state, it can be
used to denote the failure without the additional bool.
Reviewers: clayborg, zturner, espindola
Subscribers: emaste, arichardson, JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D56129
llvm-svn: 350291
|
|
|
|
| |
llvm-svn: 350281
|
|
|
|
|
|
|
| |
It doesn't like this std::tie() for some reason, hopefuly this
fixes it.
llvm-svn: 350262
|
|
|
|
|
|
| |
try_emplace is C++17.
llvm-svn: 350244
|
|
|
|
|
|
|
|
|
|
|
| |
This is a first step towards getting lldb-test symbols working
with the native plugin. There is a remaining issue, which is
that the plugin expects that ParseDeclsForContext will also
create lldb symbols rather than just the decls, but the native
pdb plugin doesn't currently do this. This will be addressed
in a followup patch.
llvm-svn: 350243
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There were several problems preventing this from working. The
first is that when the PDB had an absolute path to the main
source file, we would construct an invalid path by prepending the
compilation directory to it anyway. So we needed to check if the
path is already absolute first.
Second, LLDB assumes that the zero'th item in the support file list
is the main compilation unit. We were respecting this requirement,
but LLDB *also* requires that file to appear somewhere in the list
starting from index 1 as well. So the main compilation file should
appear in the support file list twice. And when parsing a line
table, it expects the LineEntry records to be constructed using
the 1-based index. With these two fixes we can now set breakpoints
by file and line using the native PDB reader.
llvm-svn: 350240
|
|
|
|
| |
llvm-svn: 350177
|
|
|
|
| |
llvm-svn: 350094
|
|
|
|
| |
llvm-svn: 350089
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
r346165 introduced a bug, where we would fail to parse the size of an
array if that size happened to match an existing die offset.
The logic was:
if (DWARFDIE count = die.GetReferencedDie(DW_AT_count))
num_elements = compute_vla_size(count);
else
num_elements = die.GetUsigned(DW_AT_count); // a fixed-size array
The problem with this logic was that GetReferencedDie did not take the
form class of the attribute into account, and would happily return a die
reference for any form, if its value happened to match some die.
As this behavior is inconsistent with how llvm's DWARFFormValue class
operates, I chose to fix the problem by making our version of this class
match the llvm behavior. For this to work, I had to add an explicit form
class check to the .apple_XXX tables parsing code, because they do
(incorrectly?) use data forms as die references.
Reviewers: aprantl, clayborg
Subscribers: JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D55991
llvm-svn: 350086
|
|
|
|
|
|
|
|
| |
Using compare is verbose, bug prone and potentially inefficient (because
of early termination). Replace relevant call sites with the (in)equality
operator.
llvm-svn: 349972
|
|
|
|
|
|
|
| |
We already know the final size here so we might as well reserve it so we
don't have to re-allocate during the loop.
llvm-svn: 349967
|
|
|
|
|
|
| |
Prior to this there were 3 places that were duplicating the logic to detect if a section can/should be loaded and some were doing things a bit differently. Now it is all centralized in one place and it is done correctly.
llvm-svn: 349926
|
|
|
|
|
|
|
|
|
|
| |
Previously we would create these for local variables but not for
global variables.
Also updated existing tests which created global variables to check
for them in the resulting AST.
llvm-svn: 349854
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D55841
llvm-svn: 349767
|
|
|
|
|
|
|
|
|
|
|
|
| |
__cxa_current_exception_type and add GetCurrentExceptionBacktrace SB ABI
This builds on https://reviews.llvm.org/D43884 and https://reviews.llvm.org/D43886 and extends LLDB support of Obj-C exceptions to also look for a "current exception" for a thread in the C++ exception handling runtime metadata (via call to __cxa_current_exception_type). We also construct an actual historical SBThread/ThreadSP that contains frames from the backtrace in the Obj-C exception object.
The high level goal this achieves is that when we're already crashed (because an unhandled exception occurred), we can still access the exception object and retrieve the backtrace from the throw point. In Obj-C, this is particularly useful because a catch+rethrow is very common and in those cases you currently don't have any access to the throw point backtrace.
Differential Revision: https://reviews.llvm.org/D44072
llvm-svn: 349718
|
|
|
|
|
|
|
|
|
|
|
| |
We had a use after free where we were assigning the result of a function
that returned a string to a StringRef. After fixing this use after
free, one of the DIA PDB tests now passes with the native PDB reader,
so we enable the test under native mode as well. The goal is to
eventually make all the tests pass under both, at which point we can
disable them all under DIA mode.
llvm-svn: 349673
|
|
|
|
| |
llvm-svn: 349580
|