As discussed offline, this tool is no longer used or maintained, and
doesn't provide the right abstraction for performance tracking in lldb.
Differential revision: https://reviews.llvm.org/D64362
llvm-svn: 365391
D55859 <https://reviews.llvm.org/D55859> has no effect for some of the
testcases so this patch extends it even for (all?) other testcases known to me.
LLDB was failing when LLDB prints errors reading system debug infos
(`*-debuginfo.rpm`, DWZ-optimized) which should never happen as LLDB testcases
should not be affected by system debug infos.
`lldb/packages/Python/lldbsuite/test/api/multithreaded/driver.cpp.template` is
using only SB API which does not expose `ModuleList` so I had to call
`HandleCommand()` there.
`lldb-test.cpp` could also use `HandleCommand` and then there would be no need
for `ModuleListProperties::SetEnableExternalLookup()` but I think it is cleaner
with API and not on based on text commands.
Differential Revision: https://reviews.llvm.org/D63339
llvm-svn: 363567
Problem discovered in the breakpoint lit test, but probably exists in others.
lldb-test splits lines on LF. Input files that are CR+LF separated (as is
common on Windows) then resulted in commands being sent to LLDB that ended
in CR, which confused the command interpreter.
This could be fixed at different levels:
1. Treat '\r' like a tab or space in the argument splitter.
2. Fix the line splitters (plural) in lldb-test.
3. Normalize the test files to LF only.
If we did only 3, I'd expect similar problems to recur, so this patch does
1 and 2. I may also do 3 in a separate patch later, but that's tricky
because I believe we have some input files that MUST use CR+LF.
Differential Revision: https://reviews.llvm.org/D62759
llvm-svn: 362844
Summary: The LLDB test suite doesn't need lldb-server in the framework bundle anymore.
Reviewers: JDevlieghere, jasonmolenda, xiaobai
Reviewed By: JDevlieghere
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D62474
llvm-svn: 361947
Summary:
Modify the way LLDB.framework tools are collected. This allows for better fine-tuning of the install behavior downstream. Each target calls `lldb_add_to_framework()` individually. When entering the function, the target exists and we can tweak its very own post-build and install steps. This was not possible with the old `LLDB_FRAMEWORK_TOOLS` approach.
No function change otherwise.
This is a reduced follow-up from the proposal in D61952.
Reviewers: xiaobai, compnerd, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: clayborg, friss, ki.stfu, mgorny, lldb-commits, labath, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D62472
llvm-svn: 361946
Summary:
NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]
This commit is the result of modernizing the LLDB codebase by using
`nullptr` instread of `0` or `NULL`. See
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html
for more information.
This is the command I ran and I to fix and format the code base:
```
run-clang-tidy.py \
-header-filter='.*' \
-checks='-*,modernize-use-nullptr' \
-fix ~/dev/llvm-project/lldb/.* \
-format \
-style LLVM \
-p ~/llvm-builds/debug-ninja-gcc
```
NOTE: There were also changes to `llvm/utils/unittest` but I did not
include them because I felt that maybe this library shall be updated in
isolation somehow.
NOTE: I know this is a rather large commit but it is a nobrainer in most
parts.
Reviewers: martong, espindola, shafik, #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D61847
llvm-svn: 361484
The driver passes by reference an uninitialized num_errors variable to
RunCommandInterpreter. This should be fine, as it's supposed to be
an output argument, but the reproducer instrumentation reads it in order
to record the value of all the arguments to the function.
This change fixes it by initializing num_errors to 0 before calling
RunCommandInterpreter.
llvm-svn: 361444
`terminate` overlaps with a C function on Windows:
```
D:\a\1\s\lldb\tools\lldb-server\lldb-server.cpp(45,13): warning: 'terminate' redeclared without 'dllimport' attribute: 'dllexport' attribute added [-Winconsistent-dllimport]
static void terminate() { g_debugger_lifetime->Terminate(); }
^
C:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\ucrt\corecrt_terminate.h(29,48): note: previous declaration is here
_ACRTIMP __declspec(noreturn) void __cdecl terminate() throw();
^
D:\a\1\s\lldb\tools\lldb-server\lldb-server.cpp(45,61): warning: function declared 'noreturn' should not return [-Winvalid-noreturn]
static void terminate() { g_debugger_lifetime->Terminate(); }
^
```
Rename the function to `terminate_debugger` to avoid the errant match.
llvm-svn: 360693
We cannot manipulate the LLDB_TOOL_LLDB_SERVER_BUILD directly from
LLDBConfig.cmake because this would set the variable before the option
is defined in AddLLVM.cmake. Instead, we need to use the
LLDB_CAN_USE_LLDB_SERVER variable to conditionally add the lldb-server
subdirectory. This should ensure the variable doesn't get cleared.
llvm-svn: 360631
We can piggyback off the existing add_lldb_tool_subdirectory to decide
whether or not lldb-server should be built.
Differential revision: https://reviews.llvm.org/D61872
llvm-svn: 360621
This patch adds a command line flag that allows lldb to load local
lldbinit files.
Differential revision: https://reviews.llvm.org/D61578
llvm-svn: 360172
Currently we have special handling for local lldbinit files in the
driver. At the same time, we have an SB API named
`SourceInitFileInCurrentWorkingDirectory` that does the same thing.
This patch removes the special handling from the driver and uses the API
instead. In addition to the obvious advantages of having one canonical
way of doing things and removing code duplication, this change also
means that the code path is the same for global and local lldb init
files.
Differential revision: https://reviews.llvm.org/D61577
llvm-svn: 360077
Checking this in for Antonio Afonso:
This diff changes the function LineEntry::GetSameLineContiguousAddressRange so that it also includes function calls that were inlined at the same line of code.
My motivation is to decrease the step over time of lines that heavly rely on inlined functions. I have multiple examples in the code base I work that makes a step over stop 20 or mote times internally. This can easly had up to step overs that take >500ms which I was able to lower to 25ms with this new strategy.
The reason the current code is not extending the address range beyond an inlined function is because when we resolve the symbol at the next address of the line entry we will get the entry line corresponding to where the original code for the inline function lives, making us barely extend the range. This then will end up on a step over having to stop multiple times everytime there's an inlined function.
To check if the range is an inlined function at that line I also get the block associated with the next address and check if there is a parent block with a call site at the line we're trying to extend.
To check this I created a new function in Block called GetContainingInlinedBlockWithCallSite that does exactly that. I also added a new function to Declaration for convinence of checking file/line named CompareFileAndLine.
To avoid potential issues when extending an address range I added an Extend function that extends the range by the AddressRange given as an argument. This function returns true to indicate sucess when the rage was agumented, false otherwise (e.g.: the ranges are not connected). The reason I do is to make sure that we're not just blindly extending complete_line_range by whatever GetByteSize() we got. If for some reason the ranges are not connected or overlap, or even 0, this could be an issue.
I also added a unit tests for this change and include the instructions on the test itself on how to generate the yaml file I use for testing.
Differential Revision: https://reviews.llvm.org/D61292
llvm-svn: 360071
The debug server does not need to use the instruction emulation. This
helps reduce the size of the final lldb-server binary by another ~100K
(~1% savings).
llvm-svn: 360067
We don't need the variables in lit, we can use the capabilities to check
if the utility exists.
Differential revision: https://reviews.llvm.org/D61533
llvm-svn: 359926
Summary:
According to [C128] "Virtual functions should specify exactly one
of `virtual`, `override`, or `final`", I've added override where a
virtual function is overriden but the explicit `override` keyword
was missing. Whenever both `virtual` and `override` were specified,
I removed `virtual`. As C.128 puts it:
> [...] writing more than one of these three is both redundant and
> a potential source of errors.
I anticipate a discussion about whether or not to add `override` to
destructors but I went for it because of an example in [ISOCPP1000].
Let me repeat the comment for you here:
Consider this code:
```
struct Base {
virtual ~Base(){}
};
struct SubClass : Base {
~SubClass() {
std::cout << "It works!\n";
}
};
int main() {
std::unique_ptr<Base> ptr = std::make_unique<SubClass>();
}
```
If for some odd reason somebody removes the `virtual` keyword from the
`Base` struct, the code will no longer print `It works!`. So adding
`override` to destructors actively protects us from accidentally
breaking our code at runtime.
[C128]: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#c128-virtual-functions-should-specify-exactly-one-of-virtual-override-or-final
[ISOCPP1000]: https://github.com/isocpp/CppCoreGuidelines/issues/1000#issuecomment-476951555
Reviewers: teemperor, JDevlieghere, davide, shafik
Reviewed By: teemperor
Subscribers: kwk, arphaman, kadircet, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D61440
llvm-svn: 359868
Remove unused from the driver class. I noticed a bunch of small thing
while doing this that didn't warrant separate commits, so I've lumped
them together into this patch.
llvm-svn: 359355
Summary:
Saves some build times, and they're not part of the usual
developer workflow.
Reviewers: JDevlieghere, friss
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D60780
llvm-svn: 358528
In an effort to help new LLDB developers, we added checks and messaging around
the selection of your codesigning identity on macOS. While helpful, it is not
actually correct. It's perfectly valid to codesign with an identity that is
not named lldb_codesign. Currently this fails the build.
This patch keeps a warning that informs developers how to setup lldb_codesign
and how to pass it to cmake, but it allows the build to proceed with a
different identity.
llvm-svn: 358525
A lot of comments in LLDB are surrounded by an ASCII line to delimit the
begging and end of the comment.
Its use is not really consistent across the code base, sometimes the
lines are longer, sometimes they are shorter and sometimes they are
omitted. Furthermore, it looks kind of weird with the 80 column limit,
where the comment actually extends past the line, but not by much.
Furthermore, when /// is used for Doxygen comments, it looks
particularly odd. And when // is used, it incorrectly gives the
impression that it's actually a Doxygen comment.
I assume these lines were added to improve distinguishing between
comments and code. However, given that todays editors and IDEs do a
great job at highlighting comments, I think it's worth to drop this for
the sake of consistency. The alternative is fixing all the
inconsistencies, which would create a lot more churn.
Differential revision: https://reviews.llvm.org/D60508
llvm-svn: 358135
For some reason I had convinced myself that functions returning by
pointer or reference do not require recording their result. However,
after further considering I don't see how that could work, at least not
with the current implementation. Interestingly enough, the reproducer
instrumentation already (mostly) accounts for this, though the
lldb-instr tool did not.
This patch adds the missing macros and updates the lldb-instr tool.
Differential revision: https://reviews.llvm.org/D60178
llvm-svn: 357639
Spotted some problems in the Driver's PrepareCommandsForSourcing while
helping a colleague track another problem.
1. One error case was not handled because there was no else clause.
Fixed by switching to llvm's early-out style instead of nested
`if (succes) { } else { }` cases. This keeps error handling close
to the actual error.
2. One call-site failed to call the clean-up function. I solved this
by simplifying the API. PrepareCommandsForSourcing no longer requires
the caller to provide a buffer for the pipe's file descriptors and to
call a separate clean-up function later. PrepareCommandsForSourcing
now ensures the file descriptors are handled before returning.
(The read end of the pipe is held open by the returned FILE * as
before.)
I also eliminated an unnecessary local, shorted the lifetime of another,
and tried to improve the comments.
I wrapped the call to open the pipe to get the `#ifdef`s out of the
mainline. I replaced the `close`/`_close` calls with a platform-neutral
helper from `llvm::sys` for the same reason. Per discussion on the
review, I'm leaving the `fdopen` call to use the spelling that Windows
has officially deprecated because it still works it avoids more `#ifdef`s.
Differential Revision: https://reviews.llvm.org/D60152
llvm-svn: 357626
At the moment when --repl is passed to lldb it silently ignores any
commands passed via the options below:
--one-line-before-file <command>
Tells the debugger to execute this one-line lldb command before any file provided on the command line has been loaded.
--one-line <command>
Tells the debugger to execute this one-line lldb command after any file provided on the command line has been loaded.
--source-before-file <file>
Tells the debugger to read in and execute the lldb commands in the given file, before any file has been loaded.
--source <file>
Tells the debugger to read in and execute the lldb commands in the given file, after any file has been loaded.
-O <value> Alias for --one-line-before-file
-o <value> Alias for --one-line
-S <value> Alias for --source-before-file
-s <value> Alias for --source
The -O and -S options are quite useful when writing tests for the REPL
though, e.g. to change settings prior to entering REPL mode. This
patch updates the driver to still respect the commands supplied via -O
and -S when passing --repl instead of silently ignoring them. As -s
and -o don't really make sense in REPL mode, commands supplied via
those options are still ignored, but the driver now emits a warning to
make that clear to the user.
Patch by Nathan Hawes!
Differential Revision: https://reviews.llvm.org/D59681
llvm-svn: 356911
SBError::GetCString() returns a pointer to a string owned by the SBError
object. The code here was calling GetCString on a temporary and using
the returned pointer after the temporary was destroyed.
Differential Revision: https://reviews.llvm.org/D59400
llvm-svn: 356227
If an invalid program is specified, lldb-vscode will send back a
response with "success" = false, but then will continue executing the
rest of request_launch(), try to launch the program anyway and try to
send another response (possibly using the `response` object after it was
moved).
This change adds a return statement so we stop executing the handler
after producing the first failing response.
Differential Revision: https://reviews.llvm.org/D59340
llvm-svn: 356110
Tablegen doesn't support options that are both flags and take values as
an argument. I noticed this when doing the tablegen rewrite, but forgot
that that affected the reproducer --capture flag.
This patch makes --capture a flag and adds --capture-path to specify a
path for the reproducer. In reality I expect this to be mostly used for
testing, but it could be useful nonetheless.
Differential revision: https://reviews.llvm.org/D59238
llvm-svn: 355936
I changed the variable to an unsigned to get rid of a signed and
unsigned compare without realizing the value could be negative. This
fixes the assert instead.
llvm-svn: 355708
Previously if an invalid program was specified, there was a bug
which, when we attempted to launch the program, would report that
the operation succeeded, causing LLDB to then hang while waiting
indefinitely to receive some events from the process.
After this patch, when an invalid program is specified, we immediately
return to vs code with an error message that indicates that the
program can not be found.
Differential Revision: https://reviews.llvm.org/D59114
llvm-svn: 355656
Windows can't use standard i/o system calls such as read and write
to work with sockets, it instead needs to use the specific send
and recv calls. This complicates matters for the debug adapter,
since it needs to be able to work in both server mode where it
communicates over a socket, as well as non-server mode where it
communicates via stdin and stdout. To abstract this out, I've
introduced a class IOStream which hides all these details and
exposes a read/write interface that does the right on each
platform.
Differential Revision: https://reviews.llvm.org/D59104
llvm-svn: 355637
Summary:
In 2010 (r118866), filtering code was added to debugserver to avoid reporting threads
that were "not ready to be displayed to the user". This code inspects the thread's
state and discards threads marked 'uninterruptible'. Turns out, this state is pretty
common and not only a characterisitic of 'user-readiness'. This filtering was tracked
down as the source of the flakiness of TestQueues and TestConcurrent* with the symptom
of missing threads.
We discussed with the kernel team and there should be no need for us to filter the
restult of task_threads(). Everything that is returned from there can be examined.
So I went on and tried to remove the filtering completely. This produces other test
failures, where we were reporting more theads than expected. Always threads that had
been terminated, but weren't removed from the task bookkeeping structures yet. Those
threads always had a PC of 0.
This patch changes the heuristic to make the filtering a little less strict and only
rejects threads that are 'uninteruptible' *and* have a PC of 0. This has proven to be
solid in my testing.
Reviewers: jasonmolenda, clayborg, jingham
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D58912
llvm-svn: 355555
In mail
[lldb-dev] Remote debugging a docker process
https://lists.llvm.org/pipermail/lldb-dev/2019-March/014795.html
user was confused by --min-gdbserver-port and --max-gdbserver-port options
being ignored. I think there is even a bug that --max-gdbserver-port is upper
exclusive limit (and not upper inclusive limit appropriate for max).
At least this patch should catch such mistake by an error message. The question
is whether --max-gdbserver-port should not be changed to really be max and not
max+1 but that would break backward compatibility.
Now the mail example does produce:
error: --min-gdbserver-port (5001) is not lower than --max-gdbserver-port (5001)
Differential Revision: https://reviews.llvm.org/D58962
llvm-svn: 355554
Now that the LLDB instrumentation macros are in place, we should use
that to test reproducer replay.
Differential revision: https://reviews.llvm.org/D58565
llvm-svn: 355470
Line number is a decimal number and is printed as such, however for some
reason it was prefixed with '0x', thus turning printed value invalid.
Patch by Anton Kolesov <Anton.Kolesov@synopsys.com>
llvm-svn: 354804
As per the discussion on the mailing list:
http://lists.llvm.org/pipermail/lldb-commits/Week-of-Mon-20190218/048007.html
This commit implements option (3):
> Go back to initializing the reproducer before the rest of the debugger.
> The method wouldn't be instrumented and guarantee no other SB methods are
> called or SB objects are constructed. The initialization then becomes part
> of the replay.
Differential revision: https://reviews.llvm.org/D58410
llvm-svn: 354631
Currently we'd always print the LLDB_REGISTER macro, even if the
LLDB_RECORD macro was already present. This patches changes that to make
it easier to incrementally update the macros.
Note that it's still possible for the RECORD and REGISTER macros to get
out of sync.
llvm-svn: 354400
unused IsSBProcess method, and have IsFBSProcess
return false if we don't have API that we can use to
make that determination, so we'll try other API
if we can.
llvm-svn: 354289
to a process so we'll always get messages in the console logs.
Also make the "is frontboard process" / "is backboard process"
determination lazy, specifically take it out of the
MachProcess::AttachForDebug codepath when we are attaching to a
process, to simplify attaching.
<rdar://problem/47982516>
<rdar://problem/48060134>
llvm-svn: 354181
Catch the possible error from lldb-gdbserver's main loop, and report
it verbosely. Currently, if the loop fails the server exits normally,
rendering the problem indistinguishable from regular termination.
Differential Revision: https://reviews.llvm.org/D58228
llvm-svn: 354030
The `ap` suffix is a remnant of lldb's former use of auto pointers,
before they got deprecated. Although all their uses were replaced by
unique pointers, some variables still carried the suffix.
In r353795 I removed another auto_ptr remnant, namely redundant calls to
::get for unique_pointers. Jim justly noted that this is a good
opportunity to clean up the variable names as well.
I went over all the changes to ensure my find-and-replace didn't have
any undesired side-effects. I hope I didn't miss any, but if you end up
at this commit doing a git blame on a weirdly named variable, please
know that the change was unintentional.
llvm-svn: 353912
On a local modules build this would cause an error.
> fatal error: no handler registered for module format 'obj'
> LLVM ERROR: unknown module format
Interestingly enough, this didn't trigger on the GreenDragon CMake bot,
which is configured with modules.
llvm-svn: 353869
Unlike std::make_unique, which is only available since C++14,
std::make_shared is available since C++11. Not only is std::make_shared
a lot more readable compared to ::reset(new), it also performs a single
heap allocation for the object and control block.
Differential revision: https://reviews.llvm.org/D57990
llvm-svn: 353764
Fix build errors against shared clang by adding all the libraries used
in the code.
Differential Revision: https://reviews.llvm.org/D57999
llvm-svn: 353680
GetIndexForObjectImpl generated a bunch of "conversion casts away
constness warnings". Change the function to use "const void *" (and
static_cast, while I'm at it), to avoid this.
Driver.cpp: unused variable "replay" (this was actually caused by a
subsequent partial revert of this patch). I just finish the revert by
removing the variable completely.
llvm-svn: 353405
This patch introduces a new tool called 'lldb-instr'. It automates the
workflow of inserting LLDB_RECORD and LLDB_REGSITER macros for
instrumentation.
Because the tool won't be part of the build process, I didn't want to
over-complicate it. SB_RECORD macros are inserted in place, while
SB_REGISTER macros are printed to stdout, and have to be manually copied
into the Registry's constructor. Additionally, the utility makes no
attempt to properly format the inserted macros. Please use clang-format
to format the changes after running the tool.
Differential revision: https://reviews.llvm.org/D56822
llvm-svn: 353271
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
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
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
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
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
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:
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:
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:
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
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
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
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 --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
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
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
Move code into a separate function, and replace the if-else chain with
llvm::StringSwitch.
A slight behavioral change is that now I use the section flags
(SHF_TLS) instead of the section name to set the thread-specific
property. There is no explanation in the original commit introducing
this (r153537) as to why that was done this way, but the new behavior
should be more correct.
llvm-svn: 348936
Previously, lldb-test would only print top-level sections. However, in
lldb, sections can contain other sections. This teaches lldb-test to
print nested sections too.
llvm-svn: 348924
Hopefully this makes the option data easier to understand and maintain.
- Group the member variables.
- Do the initialization in the header as it's less error prone.
- Rename the Clean method. It was called only once and was
re-initializing some but not all (?) members. The only useful thing it
does is dealing with the local lldbinit file so keep that and make the
name reflect that.
llvm-svn: 348894
This re-commits r348592, which was reverted due to a failing test on
macos.
The issue was that I was passing a null pointer for the
"CreateMemoryInstance" callback when registering ObjectFileBreakpad,
which caused crashes when attemping to load modules from memory. The
correct thing to do is to pass a callback which always returns a null
pointer (as breakpad files are never loaded in inferior memory).
It turns out that there is only one test which exercises this code path,
and it's mac-only, so I've create a new test which should run everywhere
(except windows, as one cannot delete an executable which is being run).
Unfortunately, this test still fails on linux for other reasons, but at
least it gives us something to aim for.
The original commit message was:
This patch adds the scaffolding necessary for lldb to recognise symbol
files generated by breakpad. These (textual) files contain just enough
information to be able to produce a backtrace from a crash
dump. This information includes:
- UUID, architecture and name of the module
- line tables
- list of symbols
- unwind information
A minimal breakpad file could look like this:
MODULE Linux x86_64 0000000024B5D199F0F766FFFFFF5DC30 a.out
INFO CODE_ID 00000000B52499D1F0F766FFFFFF5DC3
FILE 0 /tmp/a.c
FUNC 1010 10 0 _start
1010 4 4 0
1014 5 5 0
1019 5 6 0
101e 2 7 0
PUBLIC 1010 0 _start
STACK CFI INIT 1010 10 .cfa: $rsp 8 + .ra: .cfa -8 + ^
STACK CFI 1011 $rbp: .cfa -16 + ^ .cfa: $rsp 16 +
STACK CFI 1014 .cfa: $rbp 16 +
Even though this data would normally be considered "symbol" information,
in the current lldb infrastructure it is assumed every SymbolFile object
is backed by an ObjectFile instance. So, in order to better interoperate
with the rest of the code (particularly symbol vendors).
In this patch I just parse the breakpad header, which is enough to
populate the UUID and architecture fields of the ObjectFile interface.
The rough plan for followup patches is to expose the individual parts of
the breakpad file as ObjectFile "sections", which can then be used by
other parts of the codebase (SymbolFileBreakpad ?) to vend the necessary
information.
Reviewers: clayborg, zturner, lemo, amccarth
Subscribers: mgorny, fedor.sergeev, markmentovai, lldb-commits
Differential Revision: https://reviews.llvm.org/D55214
llvm-svn: 348773
Summary:
This patch adds the scaffolding necessary for lldb to recognise symbol
files generated by breakpad. These (textual) files contain just enough
information to be able to produce a backtrace from a crash
dump. This information includes:
- UUID, architecture and name of the module
- line tables
- list of symbols
- unwind information
A minimal breakpad file could look like this:
MODULE Linux x86_64 0000000024B5D199F0F766FFFFFF5DC30 a.out
INFO CODE_ID 00000000B52499D1F0F766FFFFFF5DC3
FILE 0 /tmp/a.c
FUNC 1010 10 0 _start
1010 4 4 0
1014 5 5 0
1019 5 6 0
101e 2 7 0
PUBLIC 1010 0 _start
STACK CFI INIT 1010 10 .cfa: $rsp 8 + .ra: .cfa -8 + ^
STACK CFI 1011 $rbp: .cfa -16 + ^ .cfa: $rsp 16 +
STACK CFI 1014 .cfa: $rbp 16 +
Even though this data would normally be considered "symbol" information,
in the current lldb infrastructure it is assumed every SymbolFile object
is backed by an ObjectFile instance. So, in order to better interoperate
with the rest of the code (particularly symbol vendors).
In this patch I just parse the breakpad header, which is enough to
populate the UUID and architecture fields of the ObjectFile interface.
The rough plan for followup patches is to expose the individual parts of
the breakpad file as ObjectFile "sections", which can then be used by
other parts of the codebase (SymbolFileBreakpad ?) to vend the necessary
information.
Reviewers: clayborg, zturner, lemo, amccarth
Subscribers: mgorny, fedor.sergeev, markmentovai, lldb-commits
Differential Revision: https://reviews.llvm.org/D55214
llvm-svn: 348592
Summary:
This parses entries in pecoff import tables for imported DLLs and
is intended as the first step to allow LLDB to load a PE's shared
modules when creating a target on the LLDB console.
Reviewers: rnk, zturner, aleksandr.urakov, lldb-commits, labath, asmith
Reviewed By: labath, asmith
Subscribers: labath, lemo, clayborg, Hui, mgorny, mgrang, teemperor
Differential Revision: https://reviews.llvm.org/D53094
llvm-svn: 348527
This patch changes the way the reproducer is initialized. Rather than
making changes at run time we now do everything at initialization time.
To make this happen we had to introduce initializer options and their SB
variant. This allows us to tell the initializer that we're running in
reproducer capture/replay mode.
Because of this change we also had to alter our testing strategy. We
cannot reinitialize LLDB when using the dotest infrastructure. Instead
we use lit and invoke two instances of the driver.
Another consequence is that we can no longer enable capture or replay
through commands. This was bound to go away form the beginning, but I
had something in mind where you could enable/disable specific providers.
However this seems like it adds very little value right now so the
corresponding commands were removed.
Finally this change also means you now have to control this through the
driver, for which I replaced --reproducer with --capture and --replay to
differentiate between the two modes.
Differential revision: https://reviews.llvm.org/D55038
llvm-svn: 348152
The changed order of includes caused compile errors on MSVC due to
snprintf macro definition. snprintf should available since VS2015, and
the rest of the code seems to be able to use snprintf just fine without
this macro, so this removes it from the lldb driver as well.
llvm-svn: 347855
They are not needed now that we use LLVMOption for command-line parsing
thank you, Jonas). This also allows us to avoid linking of lldbHost
into the driver which was breaking liblldb encapsulation.
(Technically, there is still a lldb/Host/windows/windows.h include which
is needed on windows, but this is a header-only wrapper for <windows.h>,
so it is not necessary to link lldbHost for that. But ideally, that
should go away too.)
llvm-svn: 347846
Because the optarg variable was shadowed we didn't notice we weren't
extracting the value from the option. This patch fixes that and renames
the variable to prevent this from happening in the future.
I also added two tests to check the error output for --core and --file
when the given value doesn't exist.
llvm-svn: 347821
When I landed the initial reproducer framework I knew there were some
things that needed improvement. Rather than bundling it with a patch
that adds more functionality I split it off into this patch. I also
think the API is stable enough to add unit testing, which is included in
this patch as well.
Other improvements include:
- Refactor how we initialize the loader and generator.
- Improve naming consistency: capture and replay seems the least ambiguous.
- Index providers by name and make sure there's only one of each.
- Add convenience methods for creating and accessing providers.
Differential revision: https://reviews.llvm.org/D54616
llvm-svn: 347716
This patch modifies the lldb driver to use libOption for option parsing.
It allows us to decouple option parsing from option processing which is
important when arguments affect initialization. This was previously not
possible because the debugger need to be initialized as some option
interpretation (like the scripting language etc) was handled by the
debugger, rather than in the driver.
Differential revision: https://reviews.llvm.org/D54692
llvm-svn: 347709
Summary:
Use llvm_codesign to sign debugserver with entitlements.
Set global LLVM_CODESIGNING_IDENTITY from LLDB_CODESIGN_IDENTITY (if given).
Pass through ENTITLEMENTS from add_lldb_executable to add_llvm_executable.
Handle reconfigurations correctly.
We have a lot of cases, make them explicit:
(1) build and sign debugserver, if all conditions apply:
* LLDB_NO_DEBUGSERVER=OFF (default)
* On Darwin: LLDB_USE_SYSTEM_DEBUGSERVER=OFF (default)
* On Darwin: LLVM_CODESIGNING_IDENTITY == lldb_codesign
(2) use system debugserver, if on Darwin and any of:
* LLDB_USE_SYSTEM_DEBUGSERVER=ON and found on system (explicit case)
* LLVM_CODESIGNING_IDENTITY != lldb_codesign and found on system (fallback case)
(3) debugserver will not be available, in case of:
* LLDB_NO_DEBUGSERVER=ON
* On Darwin: LLVM_CODESIGNING_IDENTITY != lldb_codesign and not found on system
(4) error state, in case of:
* LLDB_USE_SYSTEM_DEBUGSERVER=ON and not found on system
* LLDB_USE_SYSTEM_DEBUGSERVER=ON and LLDB_NO_DEBUGSERVER=ON
Reviewers: xiaobai, beanz, vsk, JDevlieghere
Subscribers: mgorny, lldb-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D54476
llvm-svn: 347305
Summary:
Highlighing junk data on VSCode can send a query for evaluate which
fails. In particular cases on Windows, this the error message can end
up as a c-string of [-35,-35,-35,-35,...]. Attempting to emplace this
as the error message causes an assert failure.
Prior to emplacing the error message, confirm that it is valid UTF8 to
eliminate errors such as mentione above.
Reviewers: xiaobai, clayborg
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D53008
llvm-svn: 346988
This patch removes the comments grouping header includes. They were
added after running IWYU over the LLDB codebase. However they add little
value, are often outdates and burdensome to maintain.
llvm-svn: 346626
This patch removes the comments following the header includes. They were
added after running IWYU over the LLDB codebase. However they add little
value, are often outdates and burdensome to maintain.
Differential revision: https://reviews.llvm.org/D54385
llvm-svn: 346625
event as a thread stop reason if we receive one, using
some macros to decode the payload.
Patch originally written by Fred Riss, with a few small changes
by myself.
Writing a test for this is a little tricky because the
mach exception data interpretation relies on header macros
or function calls - it may change over time and writing
a gdb_remote_client test for this would break as older
encoding interpretation is changed. I'll tak with Fred
about this more, but neither of us has been thrilled with
the kind of tests we could write for it.
<rdar://problem/13097323>, <rdar://problem/40144456>
llvm-svn: 346571
Summary:
The DAP on vscode uses a JavaScript `number` for identifiers while the
Visual Studio version uses a C# `Int` for identifiers. lldb-vscode is
bit shifting identifiers 32 bits and then bitwise ORing another 32 bit
identifier into a 64 bit id to form a unique ID. Change this to
a a partitioning of the 32 bits that makes sense for the data types.
Reviewers: clayborg
Differential Revision: https://reviews.llvm.org/D53599
llvm-svn: 346346
Summary:
LLVM puts output binaries in
`${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR}/bin`. This chunk of
code left out the `${CMAKE_CFG_INTDIR}`. Ultimately, the code signing target
does not need a working directory anyways, so it's safe to just remove it.
Reviewers: sas, xiaobai, beanz
Reviewed By: beanz
Subscribers: mgorny
Differential Revision: https://reviews.llvm.org/D53959
llvm-svn: 346281
Summary:
On rare occasions, the address, instruction and arguments of a line of
assembly in the CreateSource printout would reach > 60 characters. The
function would integer overflow and try to indent a line by `0xfff...`.
Change the calculated offset to be the maximum of 60 or
`line_strm.str().size()`
Reviewers: clayborg, xiaobai
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D52745
llvm-svn: 346179
Summary:
A file opened in text mode on Windows will have `\n` automatically changed to `13,10` while Darwin and Linux leave it as `10`.
Set the file to binary mode to avoid this automatic conversion so that Darwin, Linux and Windows have equivalent treatment of `\r`.
Reviewers: clayborg, xiaobai
Reviewed By: clayborg
Subscribers: emaste, ki.stfu, mgorny, eraman, JDevlieghere, mgrang
Differential Revision: https://reviews.llvm.org/D52672
llvm-svn: 346174
In January Davide sent an e-mail to the mailing list to suggest removing
unmaintained language plugins such as Go and Java. The plan was to have
some cool down period to allow users to speak up, however after that the
plugins were never actually removed.
This patch removes the OCaml debugger plugin.
The plugin can be added again in the future if it is mature enough both
in terms of testing and maintenance commitment.
Discussion on the mailing list:
http://lists.llvm.org/pipermail/lldb-dev/2018-January/013171.html
Differential revision: https://reviews.llvm.org/D54060
llvm-svn: 346159
In January Davide sent an e-mail to the mailing list to suggest removing
unmaintained language plugins such as Go and Java. The plan was to have
some cool down period to allow users to speak up, however after that the
plugins were never actually removed.
This patch removes the Java debugger plugin.
The plugin can be added again in the future if it is mature enough both
in terms of testing and maintenance commitment.
Discussion on the mailing list:
http://lists.llvm.org/pipermail/lldb-dev/2018-January/013171.html
Differential revision: https://reviews.llvm.org/D54059
llvm-svn: 346158
In January Davide sent an e-mail to the mailing list to suggest removing
unmaintained language plugins such as Go and Java. The plan was to have
some cool down period to allow users to speak up, however after that the
plugins were never actually removed.
This patch removes the Go debugger plugin.
The plugin can be added again in the future if it is mature enough both
in terms of testing and maintenance commitment.
Discussion on the mailing list:
http://lists.llvm.org/pipermail/lldb-dev/2018-January/013171.html
Differential revision: https://reviews.llvm.org/D54057
llvm-svn: 346157
This patch removes the logic for resolving paths out of FileSpec and
updates call sites to rely on the FileSystem class instead.
Differential revision: https://reviews.llvm.org/D53915
llvm-svn: 345890
This patch should not introduce any behavior changes. It consists of
mostly one of two changes:
1. Replacing fall through comments with the LLVM_FALLTHROUGH macro
2. Inserting 'break' before falling through into a case block consisting
of only 'break'.
We were already using this warning with GCC, but its warning behaves
slightly differently. In this patch, the following differences are
relevant:
1. GCC recognizes comments that say "fall through" as annotations, clang
doesn't
2. GCC doesn't warn on "case N: foo(); default: break;", clang does
3. GCC doesn't warn when the case contains a switch, but falls through
the outer case.
I will enable the warning separately in a follow-up patch so that it can
be cleanly reverted if necessary.
Reviewers: alexfh, rsmith, lattner, rtrieu, EricWF, bollu
Differential Revision: https://reviews.llvm.org/D53950
llvm-svn: 345882
Summary:
This allows creating pending breakpoint automatically when a location is not found.
This is used by some front-ends instead of doing "-break-insert -f" every time.
See also https://sourceware.org/gdb/onlinedocs/gdb/Set-Breaks.html
Signed-off-by: Marc-Andre Laperle <malaperle@gmail.com>
Subscribers: MaskRay, llvm-commits, lldb-commits, ki.stfu
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D52953
llvm-svn: 345563
was added as a part of D52604 / r343348. If the
lldb driver is run without any arguments, .lldbinit
file reading was not enabled.
<rdar://problem/45570242>
llvm-svn: 345422
Jonas Devlieghere