I want to add 512-bits support but I first want to make sure I'm
not breaking anything obvious. This is the first of a series of commit
adding tests. The first oddity found is that Scalar from APInt(s)
always constructed signed. Maybe at some point we want to revisit
this, but at least now we have a test to document how the API behaves.
<rdar://problem/46886288>
llvm-svn: 352103
Summary:
This addresses the issues raised in D56844. It removes the accessors from the
breakpad record structures by making the fields public. Also, I refactor the
UUID parsing code to remove hard-coded constants.
Reviewers: lemo
Subscribers: clayborg, lldb-commits
Differential Revision: https://reviews.llvm.org/D57037
llvm-svn: 352021
We figured out the issue so the logging is no longer necessary. It turns
out we were using a session format that was not unique for inline tests.
llvm-svn: 351902
Summary:
I did this for two reasons:
- Using the CMake packages simplifies building LLDB Standalone. This is for two
reasons: 1) We were doing a decent amount of work that is already done in the
LLVMConfig.cmake that we want to import, 2) We had to do some manual work to call
llvm-config, parse its output, and populate variables that the build system
uses.
- As far as I understand, using llvm-config makes it difficult if not impossible
to cross-compile LLDB standalone.
Reviewers: sgraenitz, labath, zturner, JDevlieghere, davide, aprantl, stella.stamenova
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D56531
llvm-svn: 351863
This patch extends SymbolFileBreakpad::AddSymbols to include the symbols
from the FUNC records too. These symbols come from the debug info and
have a size associated with them, so they are given preference in case
there is a PUBLIC record for the same address.
To achieve this, I first pre-process the symbols into a temporary
DenseMap, and then insert the uniqued symbols into the module's symtab.
Reviewers: clayborg, lemo, zturner
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D56590
llvm-svn: 351781
The new LLVM header is one line shorter than the old one, which lead to
some test failures. Ideally tests should rely on line numbers for
breakpoints or output, but that's a different discussion. Hopefully this
turns the bots green again.
llvm-svn: 351779
all missed!
Thanks to Alex Bradbury for pointing this out, and the fact that I never
added the intended `legacy` anchor to the developer policy. Add that
anchor too. With hope, this will cause the links to all resolve
successfully.
llvm-svn: 351731
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
This installs the new developer policy and moves all of the license
files across all LLVM projects in the monorepo to the new license
structure. The remaining projects will be moved independently.
Note that I've left odd formatting and other idiosyncracies of the
legacy license structure text alone to make the diff easier to read.
Critically, note that we do not in any case *remove* the old license
notice or terms, as that remains necessary until we finish the
relicensing process.
I've updated a few license files that refer to the LLVM license to
instead simply refer generically to whatever license the LLVM project is
under, basically trying to minimize confusion.
This is really the culmination of so many people. Chris led the
community discussions, drafted the policy update and organized the
multi-year string of meeting between lawyers across the community to
figure out the strategy. Numerous lawyers at companies in the community
spent their time figuring out initial answers, and then the Foundation's
lawyer Heather Meeker has done *so* much to help refine and get us ready
here. I could keep going on, but I just want to make sure everyone
realizes what a huge community effort this has been from the begining.
Differential Revision: https://reviews.llvm.org/D56897
llvm-svn: 351631
We're seeing an odd issue on GreenDragon's lldb-cmake-matrix. Dotest is
unable to move a log file (OSError: [Errno 2] No such file or
directory). The os.rename call is guarded with a check that the source
file and destination directory exist.
This wraps the call in a try-except that prints the source and
destination path to see which component seemingly doesn't exist.
llvm-svn: 351611
Summary:
This centralizes parsing of breakpad records, which was previously
spread out over ObjectFileBreakpad and SymbolFileBreakpad.
For each record type X there is a separate breakpad::XRecord class, and
an associated parse function. The classes just store the information in
the breakpad records in a more accessible form. It is up to the users to
determine what to do with that data.
This separation also made it possible to write some targeted tests for
the parsing code, which was previously unaccessible, so I write a couple
of those too.
Reviewers: clayborg, lemo, zturner
Reviewed By: clayborg
Subscribers: mgorny, fedor.sergeev, lldb-commits
Differential Revision: https://reviews.llvm.org/D56844
llvm-svn: 351541
In the original reproducer design, I expected providers to be more
dynamic than they turned out. For example, we don't have any instances
where one provider has multiple files. Additionally, I expected there to
be less locality between capture and replay, with the provider being
defined in one place and the replay code to live in another. Both
contributed to the design of the provider info.
This patch refactors the reproducer info to be something static. This
means less magic strings and better type checking. The new design still
allows for the capture and replay code to live in different places as
long as they both have access to the new statically defined info class.
I didn't completely get rid of the index, because it is useful for (1)
sanity checking and (2) knowing what files are used by the reproducer.
Differential revision: https://reviews.llvm.org/D56814
llvm-svn: 351501
In commit svn r351496 I changed this condition from
`if(LLDB_CAN_USE_DEBUGSERVER)` to `if(NOT SKIP_TEST_DEBUGSERVER)`.
This causes debugserver tests to run on windows, which shouldn't happen.
SKIP_TEST_DEBUGSERVER is set either by the user (it shouldn't be set on
windows builds) or in the debugserver CMake logic (which doesn't get
included when building on windows). Therefore, I changed the condition
to be `if(LLDB_CAN_USE_DEBUGSERVER AND NOT SKIP_TEST_DEBUGSERVER)`.
llvm-svn: 351498
Summary:
The flags `LLDB_USE_SYSTEM_DEBUGSERVER` and `LLDB_NO_DEBUGSERVER` were
introduced to the debugserver build. If one of these two flags are set, then we
do not build and sign debugserver. However I noticed that we were still building
the lldbDebugserverCommon and lldbDebugserverCommon_NonUI libraries regardless
of whether or not these flags were set. I don't believe we should be building
these libraries unless we are building and signing debugserver.
Reviewers: sgraenitz, davide, JDevlieghere, beanz, vsk, aprantl, labath
Subscribers: mgorny, jfb, lldb-commits
Differential Revision: https://reviews.llvm.org/D56763
llvm-svn: 351496
The lldb-test-depends target was using the old CMake variable name
LLDB_TEST_DEPENDS instead of LLDB_TEST_DEPS. This patch moves the target
definition and makes it use the correct one.
llvm-svn: 351489
This reapplies commit r351330, which was reverted due to a failing test on
macos. The failure was because the SymbolVendor used on MacOS was stricter than
the default (or ELF) symbol vendor, and rejected the symbol file because it's
UUID did not match the object file.
This version of the patch adds a uuid load command to the test macho file to
make sure the UUIDs match.
llvm-svn: 351447
This reapplies r350802, which was reverted because of issues with
parsing posix-style paths on windows hosts (and vice-versa). These have
since been fixed in r351328, and lldb should now recognise the path
style used in a dwarf compile unit correctly.
llvm-svn: 351435
This patch changes the behavior when printing C++ function references:
where we previously would get a <could not determine size>, there is
now a <no summary available>. It's not clear to me whether this is a
bug or an omission, but it's one step further than LLDB previously
got.
Differential Revision: https://reviews.llvm.org/D56798
llvm-svn: 351376
In this test we have deliberately removed all information which may hint
at the correct path style, so we cannot assert that lldb uses a
particular style. Instead, we should just check that it does something
vaguely reasonable.
llvm-svn: 351359
Summary:
Adding a breakpad symbol file to an existing MachO module with "target symbols
add" currently works only if one's host platform is a mac. This is
because SymbolVendorMacOSX (which is the one responsible for loading
symbols for MachO files) is conditionally compiled for the mac platform.
While we will sooner or later have a special symbol vendor for breakpad
files (to enable more advanced searching), and so this flow could be
made to work through that, it's not clear to me whether this should be a
requirement for the "target symbols add" flow to work. After all, since
the user has explicitly specified the symbol file to use, the symbol
vendor plugin's job is pretty much done.
This patch teaches the default symbol vendor to respect module's symbol
file spec, and load the symbol from that file if it is specified (and no
plugin requests any special handling).
Reviewers: clayborg, zturner, lemo
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D56589
llvm-svn: 351330
Summary:
If we opened a file which was produced on system with different path
syntax, we would parse the paths from the debug info incorrectly.
The reason for that is that we would parse the paths as they were
native. For example this meant that on linux we would treat the entire
windows path as a single file name with no directory component, and then
we would concatenate that with the single directory component from the
DW_AT_comp_dir attribute. When parsing posix paths on windows, we would
at least get the directory separators right, but we still would treat
the posix paths as relative, and concatenate them where we shouldn't.
This patch attempts to remedy this by guessing the path syntax used in
each compile unit. (Unfortunately, there is no info in DWARF which would
give the definitive path style used by the produces, so guessing is all
we can do.) Currently, this guessing is based on the DW_AT_comp_dir
attribute of the compile unit, but this can be refined later if needed
(for example, the DW_AT_name of the compile unit may also contain some
useful info). This style is then used when parsing the line table of
that compile unit.
This patch is sufficient to make the line tables come out right, and
enable breakpoint setting by file name work correctly. Setting a
breakpoint by full path still has some kinks (specifically, using a
windows-style full path will not work on linux because the path will be
parsed as a linux path), but this will require larger changes in how
breakpoint setting works.
Reviewers: clayborg, zturner, JDevlieghere
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D56543
llvm-svn: 351328
Summary:
This really is only implemented on Windows, and it requires us to pull
in User32. This was only useful when debugging on lldb-mi on Windows, and there
doesn't seem to be a good reason why using a dialog box is better than what
exists for other platforms.
Reviewers: zturner, jingham, compnerd
Subscribers: ki.stfu
Differential Revision: https://reviews.llvm.org/D56755
llvm-svn: 351276
This has been commented out since rL300111
(commit d742d081f3a1e7412cc609765139ba32d597ac15). Looks like it was
committed as a commented out line, so I'm removing it.
llvm-svn: 351263
The code in LLDB assumes that CompilerType and friends use the size 0
as a sentinel value to signal an error. This works for C++, where no
zero-sized type exists, but in many other programming languages
(including I believe C) types of size zero are possible and even
common. This is a particular pain point in swift-lldb, where extra
code exists to double-check that a type is *really* of size zero and
not an error at various locations.
To remedy this situation, this patch starts by converting
CompilerType::getBitSize() and getByteSize() to return an optional
result. To avoid wasting space, I hand-rolled my own optional data
type assuming that no type is larger than what fits into 63
bits. Follow-up patches would make similar changes to the ValueObject
hierarchy.
rdar://problem/47178964
Differential Revision: https://reviews.llvm.org/D56688
llvm-svn: 351214
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
Summary:
This patch allows to retrieve an address object for `ValueObject`'s children
retrieved through e.g. `GetChildAtIndex` or `GetChildMemberWithName`. It just
uses the corresponding method of the implementation object `m_impl` to achieve
that.
Reviewers: zturner, JDevlieghere, clayborg, labath, serge-sans-paille
Reviewed By: clayborg
Subscribers: leonid.mashinskiy, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D56147
llvm-svn: 351065
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
That is, remove many of the calls to Type::getNumContainedTypes(),
Type::subtypes(), and Type::getContainedType(N).
I'm not intending to remove these accessors -- they are
useful/necessary in some cases. However, removing the pointee type
from pointers would potentially break some uses, and reducing the
number of calls makes it easier to audit.
llvm-svn: 350835
This reverts commit r350802 because the test fails on windows. This
happens because we treat the paths as windows paths even though they
have linux path separators in the asm file. That results in wrong paths
being computed (\tmp\tmp\a.c instead of /tmp/a.c).
Reverting until I can figure out what to do with this.
llvm-svn: 350810
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
Summary:
The motivation for this is being able to write tests for the upcoming
breakpad line table parser, but this could be useful for testing the
low-level workings of any line table format. Or simply for viewing the
line table information with more detail (the brief format doesn't
include any of the flags for end_of_prologue and similar).
I've also removed the load_addresses argument from the
DumpCompileUnitLineTable function, as it wasn't being used anywhere.
Reviewers: clayborg, zturner
Subscribers: JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D56315
llvm-svn: 350802
Summary:
In python 2, strings and bytes are the same, but they're not in
python 3, hence the return of read() needs an explicit conversion.
While I'm around, rename the return of Popen() from `pipe` to
`process`, as that's what Popen returns.
Reviewers: JDevlieghere, friss, zturner, aprantl, serge-sans-paille
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D56517
llvm-svn: 350788
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
CHECK-DAG can't really be mixed with CHECK-NEXT statements because
each non DAG check sets a new search-origin for following CHECK-DAG
statements. This was passing by coincidence before, but a benign
change in the way we process symbols caused the order of the output
to be different, which triggered this test to fail.
This change makes the test resilient against ordering problems by
running a separate invocation of FileCheck for each function that
we want to test.
Note that with the Native PDB reader, we have full control over
the ordering that symbols are processed in, so we don't have
to worry about different machines returning things in different
orders due to different DIA SDK versions.
llvm-svn: 350773
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
Summary: In standalone builds `LLVM_BINARY_DIR` was equal to `LLDB_BINARY_DIR` so far. This is counterintuitive and invalidated the values of `LLDB_DEFAULT_TEST_DSYMUTIL/FILECHECK/COMPILER` etc.
Reviewers: zturner, labath, clayborg, JDevlieghere, stella.stamenova, serge-sans-paille
Reviewed By: labath
Subscribers: mgorny, friss, lldb-commits, #lldb
Differential Revision: https://reviews.llvm.org/D56443
llvm-svn: 350738
Summary: Handle standalone builds separately and print a warning if we have no libcxx.
Reviewers: aprantl, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: mgorny, lldb-commits, #lldb
Differential Revision: https://reviews.llvm.org/D56399
llvm-svn: 350737
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
I was looking at the code in BreakpointList.cpp and found it deserved a
quick cleanup.
- Use std::vector instead of a std::list.
- Extract duplicate code for notifying.
- Remove code duplication when returning a const value.
- Use range-based for loop.
- Use early return in loops.
Differential revision: https://reviews.llvm.org/D56425
llvm-svn: 350659
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
Summary:
In standalone builds of LLDB we currently have no target `count` that tests can depend on. This may be fixed in the future by exporting the target from LLVM similar to targets llvm-config, dsymutil and others.
In-tree build with this patch:
```
$ ninja -t query tools/lldb/lit/check-lldb-lit
tools/lldb/lit/check-lldb-lit:
input: phony
tools/lldb/lit/CMakeFiles/check-lldb-lit
bin/FileCheck
bin/clang
bin/count
bin/darwin-debug
bin/debugserver
bin/dsymutil
bin/llc
bin/lldb
bin/lldb-mi
bin/lldb-server
bin/lldb-test
bin/llvm-config
bin/llvm-mc
bin/llvm-objcopy
bin/not
bin/yaml2obj
lib/liblldb.dylib
projects/libcxx/lib/cxx
tools/lldb/unittests/LLDBUnitTests
outputs:
tools/lldb/test/check-lldb
check-lldb-lit
```
Standalone build with this patch:
```
$ ninja -t query lit/check-lldb-lit
lit/check-lldb-lit:
input: phony
lit/CMakeFiles/check-lldb-lit
bin/darwin-debug
bin/debugserver
bin/lldb
bin/lldb-mi
bin/lldb-server
bin/lldb-test
lib/liblldb.dylib
unittests/LLDBUnitTests
outputs:
test/check-lldb
check-lldb-lit
```
Reviewers: davide, aprantl, JDevlieghere, alexshap
Reviewed By: davide
Subscribers: mgorny, lldb-commits, #lldb
Differential Revision: https://reviews.llvm.org/D56389
llvm-svn: 350538
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
D55859 changed "external tools or libraries" to "external sources" according to
Pavel Labath. Now it is changed sort of back to "external tools and
repositories" according to Adrian Prantl.
https://reviews.llvm.org/D55859#1345881
llvm-svn: 350479
Summary:
Simplify SWIG invocation and handling of generated files.
The `swig_wrapper` target can generate `LLDBWrapPython.cpp` and `lldb.py` in its own binary directory, so we can get rid of a few global variables and their logic. We can use the swig_wrapper's BINARY_DIR target property to refer to it and liblldb's LIBRARY_OUTPUT_DIRECTORY to refer to the framework/shared object output directory.
Reviewers: JDevlieghere, aprantl, stella.stamenova, beanz, zturner, xiaobai
Reviewed By: aprantl
Subscribers: mgorny, lldb-commits, #lldb
Differential Revision: https://reviews.llvm.org/D55332
llvm-svn: 350393
Summary:
If we build LLDB.framework, dependant tools need appropriate RPATHs in both locations, the build-tree (for testing) and the install-tree (for deployment). Luckily, CMake can handle it for us: https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/RPATH-handling.
* In the build-tree, tools use the absolute path to the framework's actual output location.
* In the install-tree, tools get a list of RPATHs to look for the framework when deployed.
`LLDB_FRAMEWORK_INSTALL_DIR` is added to the `CMAKE_INSTALL_PREFIX` to change the relative location of LLDB.framework in the install-tree.
If it is not empty, it will be added as an additional RPATH to all dependant tools (so they are functional in the install-tree).
If it is empty, LLDB.framework goes to the root and tools will not be functional in the directory structure of the LLVM install-tree.
For historical reasons `LLDB_FRAMEWORK_INSTALL_DIR` defaults to "Library/Frameworks".
Reviewers: xiaobai, JDevlieghere, aprantl, clayborg
Reviewed By: JDevlieghere
Subscribers: ki.stfu, mgorny, lldb-commits, #lldb
Differential Revision: https://reviews.llvm.org/D55330
llvm-svn: 350392
Summary:
Add features to LLDB CMake builds that have so far only been available in Xcode. Clean up a few inconveniences and prepare further improvements.
Options:
* `LLDB_FRAMEWORK_BUILD_DIR` determines target directory (in build-tree)
* `LLDB_FRAMEWORK_INSTALL_DIR` **only** determines target directory in install-tree
* `LLVM_EXTERNALIZE_DEBUGINFO` allows externalized debug info (dSYM on Darwin, emitted to `bin`)
* `LLDB_FRAMEWORK_TOOLS` determines which executables will be copied to the framework's Resources (dropped symlinking, removed INCLUDE_IN_SUITE, removed dummy targets)
Other changes:
* clean up `add_lldb_executable()`
* include `LLDBFramework.cmake` from `source/API/CMakeLists.txt`
* use `*.plist.in` files, which are typical for CMake and independent from Xcode
* add clang headers to the framework bundle
Reviewers: xiaobai, JDevlieghere, aprantl, davide, beanz, stella.stamenova, clayborg, labath
Reviewed By: aprantl
Subscribers: friss, mgorny, lldb-commits, #lldb
Differential Revision: https://reviews.llvm.org/D55328
llvm-svn: 350391
Summary:
One place for debugserver options, analog to LLDBConfig for LLDB options (see D55317). It was discussed in earlier reviews already, e.g. D55013.
Reviewers: JDevlieghere, aprantl, xiaobai
Reviewed By: aprantl, xiaobai
Subscribers: mgorny, lldb-commits, #lldb
Differential Revision: https://reviews.llvm.org/D55320
llvm-svn: 350390
Summary:
Major fixes after D54476 (use Diff1 as base for comparison to see only recent changes):
* In standalone builds target directory for debugserver must be LLDB's bin, not LLVM's bin
* Default identity for code signing must not force-override LLVM_CODESIGNING_IDENTITY globally
We have a lot of cases, make them explicit:
* ID used for code signing (debugserver and in tests):
** `LLDB_CODESIGN_IDENTITY` if set explicitly, or otherwise
** `LLVM_CODESIGNING_IDENTITY` if set explicitly, or otherwise
** `lldb_codesign` as the default
* On Darwin we have a debugserver target that:
* On other systems, the debugserver target is not defined, which is equivalent to **[3A]**
Common configurations on Darwin:
* **[1A]** `cmake -GNinja ../llvm` builds debugserver from source and signs with `lldb_codesign`, no code signing for other binaries (prints status: //lldb debugserver: /path/to/bin/debugserver//)
* **[1A]** `cmake -GNinja -DLLVM_CODESIGNING_IDENTITY=- -DLLDB_CODESIGN_IDENTITY=lldb_codesign ../llvm` builds debugserver from source and signs with `lldb_codesign`, ad-hoc code signing for other binaries (prints status: //lldb debugserver: /path/to/bin/debugserver//)
* **[2A]** `cmake -GNinja -DLLVM_CODESIGNING_IDENTITY=- -DLLDB_USE_SYSTEM_DEBUGSERVER=ON ../llvm` copies debugserver from system, ad-hoc code signing for other binaries (prints status: //Copy system debugserver from: /path/to/system/debugserver//)
* **[2B]** `cmake -GNinja -DLLVM_CODESIGNING_IDENTITY=- ../llvm` same, but prints additional warning: //Cannot code sign debugserver with identity '-'. Will fall back to system's debugserver. Pass -DLLDB_CODESIGN_IDENTITY=lldb_codesign to override the LLVM value for debugserver.//
* **[3A]** `cmake -GNinja -DLLVM_CODESIGNING_IDENTITY=- -DLLDB_NO_DEBUGSERVER=ON ../llvm` debugserver not available (prints status: //lldb debugserver will not be available)//
Reviewers: JDevlieghere, beanz, davide, vsk, aprantl, labath
Reviewed By: JDevlieghere, labath
Subscribers: mgorny, #lldb, lldb-commits
Differential Revision: https://reviews.llvm.org/D55013
llvm-svn: 350388
Summary:
The implementation in CalculateSymbolSizes has been made redundant in
D19004, as this patch added another copy of size computation code into
InitAddressIndexes (which is called by CalculateSymbolSizes).
Reviewers: clayborg, jasonmolenda, tberghammer
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D56132
llvm-svn: 350384
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
There is already in use:
lit/lit-lldb-init:
settings set symbols.enable-external-lookup false
packages/Python/lldbsuite/test/lldbtest.py:
self.runCmd('settings set symbols.enable-external-lookup false')
But those are not in effect during MI part of the testsuite. Another problem is
that symbols.enable-external-lookup (read by GetEnableExternalLookup) has been
currently read only by LocateMacOSXFilesUsingDebugSymbols and therefore it had
no effect on Linux.
On Red Hat platforms (Fedoras, RHEL-7) there is DWZ in use and so
MiSyntaxTestCase-test_lldbmi_output_grammar FAILs due to:
AssertionError: error: inconsistent pattern ''^.+?\n'' for state 0x5f
(matched string: warning: (x86_64) /lib64/libstdc++.so.6 unsupported
DW_FORM values: 0x1f20 0x1f21
It is the only testcase with this error. It happens due to:
(lldb) target create "/lib64/libstdc++.so.6"
Current executable set to '/lib64/libstdc++.so.6' (x86_64).
(lldb) b main
warning: (x86_64) /lib64/libstdc++.so.6 unsupported DW_FORM values: 0x1f20 0x1f21
Breakpoint 1: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.
which happens only with gcc-base-debuginfo rpm installed (similarly for other packages).
It should also speed up the testsuite as it no longer needs to read
/usr/lib/debug symbols which have no effect (and should not have any effect) on
the testsuite results.
Differential Revision: https://reviews.llvm.org/D55859
llvm-svn: 350368
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
This is an alternate patch for the bug reported in
https://bugs.llvm.org/show_bug.cgi?id=39816 ("lldb doesn't show a file
of line entry for big project"). This limits the number of lines in a
source file to 32M, which I think is reasonable even for preprocessed
source inputs.
Differential Revision: https://reviews.llvm.org/D56218
llvm-svn: 350274
TestQueues is failing randomly on green dragon and I suspect it is
because the enqueued threads haven't executed by the time we expect
them. This patch adds file-based synchronization to the queues.
Differential Revision: https://reviews.llvm.org/D56208
llvm-svn: 350247
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
A Previous patch added support for creating VarDecls for global
variables. This patch updates this test to be more strict and
actually check these, not just the types.
llvm-svn: 350242
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
The warning comes from the fact that the MOCK_METHOD macros don't use the
override keyword internally. This makes us not use it in the manually overriden
methods either, to be consistent.
llvm-svn: 350209
Simplify some code in PreprocessCommand. This change improves
consistency, reduces the indentation and makes the code easier to follow
overall.
llvm-svn: 350166
python 3.7 removes re._pattern_type. Fix the one place where we were
depending on the type of regular expressions to compute the type
dynamically.
llvm-svn: 350093
The assertion fired (with a debug visual studio STL) because we tried to
dereference the end of a vector (although it was only to take its
address again and form an end iterator). Rewrite this logic to avoid the
questionable code.
llvm-svn: 350091
Summary:
Simplify the code by using the contains implementation in IntervalMap.
There is a slight change of behavior here: We now treat an allocation of
size 0, as if it was size 1. This guarantees that the returned addresses
will be unique, whereas previously we would allow the allocation
function to return the same zero-sized region multiple times, as long as
it is not null, and not in the middle of an existing interval (but the
situation when we were placing an larger interval over a zero-sized one
was not detected).
I think this behavior makes more sense, as that is pretty much the same
guarantee as offered by malloc (except that is permitted to also return
nullptr).
Reviewers: vsk
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D55761
llvm-svn: 350087
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
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
They both run the same command, and people get used to typing the shortest
string they can, so we should support alias info on shortened strings as well.
<rdar://problem/46859207>
llvm-svn: 349874
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
These are tests that found actual, but hard to fix, bugs that are
tracked elsewhere. Leaving them red only distracts from new failures
this bot finds.
llvm-svn: 349851
Unexpected successes should be considered failures because they can hide
regressions when not addressed. When a test is fixed and not re-enabled,
it can easily regress without us noticing.
I couldn't find a good way to make this change other than changing it in
the unittest2 framework. I know this is less than optimal but since we
have the dependency checked in and the change is pretty fundamental to
the framework I think it's not unreasonable.
Differential revision: https://reviews.llvm.org/D55835
llvm-svn: 349818
This test is now marked as unsupported on Windows - it is not technically "unsupported" on Windows, but it fails because "expr ptr" does not evaluate correctly. However, the error message contains the expected string, so the test "passes" despite the fact that the commands failed
The following bug has been opened for it: llvm.org/pr40119
llvm-svn: 349784
This is a set of tests that were all marked as failing becuse of pr24764. The bug is not fixed (as in more of the tests that were marked this way are failing), but this set is passing. It is possible that some of them are false positives, but there's a large number of unexpectedly passing tests on Windows, so I am doing a bulk un-xfail to get the buildbot to green.
llvm-svn: 349719
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
This is a set of tests that were all marked as failing becuse of several different bugs. A couple of the bugs are now resolved as fixed since all the tests that were failing associated with the bug are now passing. It is possible that some of them are false positives, but there's a large number of unexpectedly passing tests on Windows, so I am doing a bulk un-xfail to get the buildbot to green.
llvm-svn: 349713
This is a set of tests that were all marked as failing becuse of several different bugs. A couple of the bugs are now resolved as fixed since all the tests that were failing associated with the bug are now passing. It is possible that some of them are false positives, but there's a large number of unexpectedly passing tests on Windows, so I am doing a bulk un-xfail to get the buildbot to green.
llvm-svn: 349711
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
This is a set of tests that were all marked as failing becuse of pr21765. The bug is not fixed (as in more of the tests that were marked this way are failing), but this set is passing. It is possible that some of them are false positives, but there's a large number of unexpectedly passing tests on Windows, so I am doing a bulk un-xfail to get the buildbot to green.
llvm-svn: 349668
This is a set of tests that were all marked as failing becuse of pr24489. The bug is not fixed (as in more of the tests that were marked this way are failing), but this set is passing. It is possible that some of them are false positives, but there's a large number of unexpectedly passing tests on Windows, so I am doing a bulk un-xfail to get the buildbot to green.
llvm-svn: 349665
Prior to this change we would show the name of the section that a memory region belonged to but not its actual region name. Now we show this,. Added a test that reuses the regions-linux-map.dmp minidump file to test this and verify the correct region names for various memory regions.
Differential Revision: https://reviews.llvm.org/D55854
llvm-svn: 349658
The build.py script always runs the compiler in C++ mode, regardless of
the file extension. This results in mangled names presented to the
linker which in turn cannot find the printf symbol.
While we figure out how to solve this issue I've turned the source file
into a cpp file and added extern c. This should unbreak the bots.
llvm-svn: 349642
Currently spawnLldbMi accepts both lldb-mi options and executable to debug as
a single parameter. Split them.
As in D55859 we will need to execute one lldb-mi command before loading the
exe. Therefore we can no longer use the exe as lldb-mi command-line parameter
as then there is no way to execute a command before loading exe specified as
lldb-mi command-line parameter.
LocateExecutableSymbolFileDsym should be static, that is also a little
refactorization.
Differential Revision: https://reviews.llvm.org/D55858
llvm-svn: 349607
We're linking against libcompression all the time now, we don't need to
fall back to zlib. zlib support will still be used when lldb is built on
linux et al systems, so I'm not removing any of the source support, but
when built on darwin with xcode, we'll be using libcompression.
llvm-svn: 349572
We reconstruct the AST hierarchy by trying to hack up a mangled
name for the parent type using the child type's mangled name.
This was failing for enums because their tag type is represented
with two letters ("W4") instead of one letter ("T", "U", etc) as
it is with classes, structs, and unions. After accounting for
this we can now correctly determine when an enum is nested
inside of a namespace or a class.
llvm-svn: 349565
systems. It has been available in the OS over over three years
now. If lldb doesn't link against -lcompression, it should be an
error.
Allocate a scratch buffer for libcompression to use when decoding
packets, instead of it having to allocate & free one on every call.
Fix a typeo with the size of the buffer that compression_decode_buffer()
is expanding into.
<rdar://problem/41601084>
llvm-svn: 349563
on Darwin systems and libcompression has been in the OS for over
three years.
Remove use of / linking to zlib. We'll always have libcompression
available now.
Create a scratch buffer via compression_encode_scratch_buffer_size()
and use it in calls to compression_encode_buffer() to avoid
compression_encode_buffer having to malloc & free a scratch buffer
on each call.
Tested by forcing compression to be enabled on macos native (normally
only enabled on iOS et al devices), running the testsuite.
<rdar://problem/41601084>
llvm-svn: 349553
As discussed on IRC this morning, when building an in-tree clang for
testing we have to have libcxx and libcxxabi checked out. This is a
common pitfall. Not only are the resulting failures non-obvious, they
only manifest when running the test suite, *after* building lldb and
clang. By making them a hard dependency (on macOS) we fail earlier with
a more useful error message.
Differential revision: https://reviews.llvm.org/D55837
llvm-svn: 349539
Summary:
GnuWin32 installs libxml2 2.4. This isn't recent enough for lldb's
usage and thus the build fails. Searching for libxml2 was disabled
due to this build failure.
However, the gdb-remote plugin requires libxml2 to parse various
gdb-remote protocol packets. Thus check and confirm that the libxml2
version is at least 2.8 and disable it if not.
Reviewers: compnerd, zturner
Reviewed By: compnerd
Subscribers: mgorny
Differential Revision: https://reviews.llvm.org/D55583
llvm-svn: 349538
Summary:
The first section header does not define a real section. Instead it is
used for various elf extensions. This patch skips creation of a section
for index 0.
This has one furtunate side-effect, in that it allows us to use the section
header index as the Section ID (where 0 is also invalid). This way, we
can get rid of a lot of spurious +1s in the ObjectFileELF code.
Reviewers: clayborg, krytarowski, joerg, espindola
Subscribers: emaste, lldb-commits, arichardson
Differential Revision: https://reviews.llvm.org/D55757
llvm-svn: 349498
the "self.assertEqual(thread.GetStopReason(), lldb.eStopReasonSignal)"
was occasionally failing because the stop reason would come out as
"trace" this happened if we issued the interrupt just as the processed
stopped due to single-stepping over the breakpoint (i.e., the it was not
necessary to send any signal).
Fix this by removing the breakpoint before resuming the process. This
ensures the process can run unobstructed.
After this, the test passed 200 consecutive runs successfully for me,
even while the system was under heavy load.
llvm-svn: 349491
This test was disabled in r326756 as a part of "upstreaming debugserver
support for AVX-512 (zmm register set)". This looks like an error
because both register set and remote stubs are different.
In any case, the test passes now.
llvm-svn: 349485
This test is passing now on linux. The same test is claimed to be flaky
on darwin, so it's possible that's true on linux too. If that's the case
we'll have to skip it here too (or fix it).
I mark the test as not-debug-info-dependent as a drive-by.
llvm-svn: 349482
These tests are now passing on linux, at least with top-of-tree clang,
clang-6 and gcc-7.3. It's possible it may still be failing with some
older compilers, but I don't have those around to test.
llvm-svn: 349478
Summary:
This should enable the compiler to find the system linker for the link
step.
Reviewers: stella.stamenova, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D55736
llvm-svn: 349461
We need to ensure that Finalize gets called before we start
to destroy the old Process or the weak_ptr->shared_ptr link
from Threads to Target gets broken before the threads are
destroyed.
<rdar://problem/43586979>
Differential Revision: https://reviews.llvm.org/D55631
llvm-svn: 349435
Each process plug-in can create its own custom commands. I figured it would be nice to be able to dump things from the minidump file from the lldb command line, so I added the start of the some custom commands.
Currently you can dump:
minidump stream directory
all linux specifc streams, most of which are strings
each linux stream individually if desired, or all with --linux
The idea is we can expand the command set to dump more things, search for data in the core file, and much more. This patch gets us started.
Differential Revision: https://reviews.llvm.org/D55727
llvm-svn: 349429
present in the dSYM per-uuid plist, its precedence order with
the older DBGBuildSourcePath/DBGSourcePath, and note that
must be present and have a value of 3 or the dictionary
will be ignored.
<rdar://problem/46421686>
llvm-svn: 349409
make the executable name more unique.
This test is failing sporadically on some bots. By removing the sleep
synchronisation, I'm hoping to get it to fail more reproducibly so I
can investigate what is going on.
llvm-svn: 349397
Previously the code that parsed debug info to create lldb's Symbol
objects such as Variable, Type, Function, etc was tightly coupled
to the AST reconstruction code. This made it difficult / impossible
to implement functions such as ParseDeclsForContext() that were only
supposed to be operating on clang AST's. By splitting these apart,
the logic becomes much cleaner and we have a clear separation of
responsibilities.
llvm-svn: 349383
The --repl option was incorrectly defined as "Separate" (option and
value separated by a space). This resulted in the option not being
picked up when no value was specified.
This patch fixes the driver so that `--repl` is recognized again. I
split the option into two:
- A flag: `--repl` and `-r` which take no arguments.
- A joined option: `--repl=<flags>` and `-r=<flags>` that forward its
values to the repl.
This should match the driver's old behavior.
llvm-svn: 349371
This is a little dangerous since the crashlog files aren't 100%
unambiguous, but the risk is mitigated by using a non-greedy +?
pattern.
rdar://problem/38478511
Differential Revision: https://reviews.llvm.org/D55608
llvm-svn: 349367
Often users have a crash log an d a .dSYM bundle, but not the original
application binary. It turns out that for crash symbolication, we can
safely fall back to using the binary inside the .dSYM bundle.
Differential Revision: https://reviews.llvm.org/D55607
llvm-svn: 349366
The first one allows us to add an enumerator to an enum if we
already have an APSInt, since ultimately the implementation just
constructs one anyway. The second is just a general utility
function to covert a CompilerType to a clang::TagDecl.
llvm-svn: 349360
gdb-remote serial protocol documentation, call out the
incompatability of lldb's vFile:open: packet as it stands
today. Need to think about whether to change lldb's
enum values (breaking any existing lldb-server's out there)
or create a different packet and abandon vFile:open: at
least for a while.
llvm-svn: 349316
in the packet are lldb enum values, not the open(2) oflags --
forgot about that wrinkle. Also added a comment to File.h
noting that the existing values cannot be modified or we'll
have a compatibilty break with any alternative platform
implementations, or older versions of lldb-server.
llvm-svn: 349282
Summary:
Previously lldb-test's LinePrinter would output the indentation spaces
even on completely empty lines. This is not nice, as trailing spaces get
flagged as errors in some tools/editors, and it prevents FileCheck's
CHECK-EMPTY from working.
Equally annoying was the fact that the LinePrinter did not terminate
it's output with a newline (instead it would leave the unterminated hanging
indent from the last NewLine() command), which meant that the shell prompt
following the lldb-test command came out wrong.
This fixes both issues by changing how newlines are handled. NewLine(),
which was ending the previous line ('\n') *and* begging the next line by
printing the indent, is now "demoted" to just printing literal "\n".
Instead, lines are now delimited via a helper Line object, which makes
sure the line is indented and terminated in an RAII fashion. The typical
usage would be:
Printer.line() << "This text will be indented and terminated";
If one needs to do more work than it will fit into a single statement,
one can also assign the result of the line() function to a local
variable. The line will then be terminated when that object goes out of
scope.
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D55597
llvm-svn: 349269
Summary:
This patch attempts to move as much code as possible out of the
CreateSections function to make room for future improvements there. Some
of this may be slightly over-engineered (VMAddressProvider), but I
wanted to keep the logic of this function very simple, because once I
start taking segment headers into acount (as discussed in D55356), the
function is going to grow significantly.
While in there, I also added tests for various bits of functionality.
This should be NFC, except that I changed the order of hac^H^Heuristicks
for determining section type slightly. Previously, name-based deduction
(.symtab -> symtab) would take precedence over type-based (SHT_SYMTAB ->
symtab) one. In fact we would assert if we ran into a .text section with
type SHT_SYMTAB. Though unlikely to matter in practice, this order
seemed wrong to me, so I have inverted it.
Reviewers: clayborg, krytarowski, espindola
Subscribers: emaste, arichardson, lldb-commits
Differential Revision: https://reviews.llvm.org/D55706
llvm-svn: 349268
to write an lldb platform server that doesn't link against
LLDB.framework to be able to fully run the lldb testsuite
on a remote system. The platform packets weren't covered
in the existing lldb-gdb-remote.txt doc, so I wanted to
jot them down in one place.
llvm-svn: 349231
This patch simplifies boolean expressions acorss LLDB. It was generated
using clang-tidy with the following command:
run-clang-tidy.py -checks='-*,readability-simplify-boolean-expr' -format -fix $PWD
Differential revision: https://reviews.llvm.org/D55584
llvm-svn: 349215
While I was out hunting for remaining pexpect-based tests, I came
across these tests that can't possibly work an any modern system, as
they rely on having gdb available in /Developer.
This patch simply removes the test without replacement.
Differential Revision: https://reviews.llvm.org/D55559
llvm-svn: 349194
Davide Italiano