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
Michal Gorny