| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 351879
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
files
llvm-svn: 351830
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 351760
|
| |
|
|
| |
llvm-svn: 351733
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 351707
|
| |
|
|
| |
llvm-svn: 351703
|
| |
|
|
|
|
|
|
|
|
| |
The format for the -w argument is:
-w name ( --category name )
Rearrange the flags correctly.
llvm-svn: 351664
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 351585
|
| |
|
|
|
|
|
|
| |
backtrace using EH frame, it works.
Prior to this, backtraces could fail due to not being able to convert a EH frame register number to LLDB register number.
llvm-svn: 351564
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
Fix fallout from r351501 in the reproducer unittest.
llvm-svn: 351524
|
| |
|
|
| |
llvm-svn: 351504
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
The lldbtest format was incorrectly detecting XFAIL as FAIL because it
was looking for the `FAIL:` substring in the dotest output.
llvm-svn: 351497
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
debugserver builds
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
|
| |
|
|
|
|
|
|
|
| |
we don't use a thumb code section.
Don't run Test128BitsInteger.py on armv7k; it's not a supported
type on that target.
llvm-svn: 351490
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 351486
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
module.GetSymbolFileFileSpec()"
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
|
| |
|
|
|
|
|
|
|
|
|
| |
a .debug_line test"
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
|
| |
|
|
|
|
| |
http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/677/steps/test/logs/stdio
llvm-svn: 351385
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
module.GetSymbolFileFileSpec()"
This reverts commit r351330 due to failures on MacOS bots.
llvm-svn: 351353
|
| |
|
|
|
|
|
| |
This avoids the "ambiguous else" warning, which comes from within the
EXPECT_TRUE macro.
llvm-svn: 351331
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
This reverts commit r351250 because it breaks the
SymbolFile/NativePDB/function-types-builtins.cpp.
llvm-svn: 351327
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is https://bugs.llvm.org/show_bug.cgi?id=40112,
Currently, lldb crashes after pressing the up arrow key when listing the history for expressions.
The patch fixes the mistype that was a reason.
Differential revision: https://reviews.llvm.org/D56014
llvm-svn: 351313
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 351274
|
| |
|
|
| |
llvm-svn: 351264
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 351250
|
| |
|
|
| |
llvm-svn: 351244
|
| |
|
|
| |
llvm-svn: 351243
|
| |
|
|
|
|
| |
This addresses post-commit feedback for https://reviews.llvm.org/D56688
llvm-svn: 351237
|
| |
|
|
| |
llvm-svn: 351215
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
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
|