Fix processing of "C" packet with signal for the whole process to
default signal value for action list to LLDB_INVALID_SIGNAL_NUMBER
rather than 0.
Differential Revision: https://reviews.llvm.org/D67625
llvm-svn: 372090
The LoadScriptingModule used by command script import wasn't
initializing the LLDB global variables (things like `lldb.frame` and
`lldb.debugger`). They would get initialized however when running the
interactive script interpreter or running a single script line (e.g.
`script print(lldb.frame)`). This patch fixes that by properly
initializing the globals when loading a Python module.
Differential revision: https://reviews.llvm.org/D67644
llvm-svn: 372060
This reverts commit 21641a2f6d.
It was causing the following test failures:
lldb-Suite.lang/objc/objc-class-method.TestObjCClassMethod.py
lldb-Suite.lang/objc/foundation.TestObjCMethodsString.py
lldb-Suite.lang/objc/foundation.TestConstStrings.py
lldb-Suite.lang/objc/radar-9691614.TestObjCMethodReturningBOOL.py
lldb-Suite.lang/objc/foundation.TestObjCMethodsNSArray.py
llvm-svn: 372057
This patch completes the dump functionality by adding support for
dumping a reproducer's GDB remote packets.
Differential revision: https://reviews.llvm.org/D67636
llvm-svn: 372046
This moves the dumping logic from the GDBRemoteCommunicationHistory
class into the GDBRemotePacket so that it can be reused from the
reproducer command object.
llvm-svn: 372028
This adds a reproducer dump commands which makes it possible to inspect
a reproducer from inside LLDB. Currently it supports the Files, Commands
and Version providers. I'm planning to add support for the GDB Remote
provider in a follow-up patch.
Differential revision: https://reviews.llvm.org/D67474
llvm-svn: 371909
To support dumping the reproducer's GDB remote packets, we need the
(de)serialization logic to live in Utility rather than the GDB remote
plugin. This patch renames StreamGDBRemote to GDBRemote and moves the
relevant packet code there.
Its uses in the GDBRemoteCommunicationHistory and the
GDBRemoteCommunicationReplayServer are updated as well.
Differential revision: https://reviews.llvm.org/D67523
llvm-svn: 371907
The StringRef should always be identical to the C string, so we
might as well just create the StringRef from the C-string. This
might be slightly slower until we implement the storage of ArgEntry
with a string instead of a std::unique_ptr<char[]>. Until then we
have to do the additional strlen on the C string to construct the
StringRef.
llvm-svn: 371842
This code is not on any performance critical path that would
justify this shortening optimization. It also makes it possible
to turn 'ref' into a function (as this is the only place where
we modify this ArgEntry member).
llvm-svn: 371836
levels:
-- none: no lax vector conversions [new GCC default]
-- integer: only conversions between integer vectors [old GCC default]
-- all: all conversions between same-size vectors [Clang default]
For now, Clang still defaults to "all" mode, but per my proposal on
cfe-dev (2019-04-10) the default will be changed to "integer" as soon as
that doesn't break lots of testcases. (Eventually I'd like to change the
default to "none" to match GCC and general sanity.)
Following GCC's behavior, the driver flag -flax-vector-conversions is
translated to -flax-vector-conversions=integer.
This reinstates r371805, reverted in r371813, with an additional fix for
lldb.
llvm-svn: 371817
Summary:
InferiorCall is only ever used in Process, and it is not specific to
POSIX. By moving it to Process, we can remove all dependencies on plugins from
Process. Moving InferiorCall to Process seems to achieve this quite well.
Additionally, the name InferiorCall is a little vague now, so we rename
it something a bit more specific.
Reviewers: JDevlieghere, clayborg, compnerd, labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67472
llvm-svn: 371796
This just moves the CommandLoader utility into the reproducer namespace
and makes it accessible outside the API layer. This is setting things up
for a bigger change.
llvm-svn: 371689
Originally the idea was for providers to be defined close to where they
are used. While this helped designing the providers in such a way that
they don't depend on each other, it also means that it's not possible to
access them from a central place. This proved to be a problem for some
providers and resulted in them living in the reproducer class.
The ProcessGDBRemote provider is the last remaining exception. This
patch makes things consistent and moves it into the reproducer like the
other providers.
llvm-svn: 371685
Add support for evaluating DW_OP_entry_value. This involves parsing
DW_TAG_call_site_parameter and wiring the information through to the expression
evaluator.
rdar://54496008
Differential Revision: https://reviews.llvm.org/D67376
llvm-svn: 371668
Summary:
InferiorCallPOSIX directly grabs a ClangASTContext from the Target it
has and does no error checking. I don't think these functions have a
reason to know about clang specifically. Additionally, using
`GetScratchTypeSystemForLanguage` forces us to do error checking since
it returns an Expected.
Differential Revision: https://reviews.llvm.org/D67427
llvm-svn: 371654
We never compare these directories (where ConstString would be good) and
essentially just convert this back to a normal string in the end. So we might
as well just use std::string. Also makes it easier to unittest this code
(which was the main motivation for this change).
llvm-svn: 371623
Summary:
This change ensures that the .dynsym section will be parsed even when there's already is a .symtab.
It is motivated because of minidebuginfo (https://sourceware.org/gdb/current/onlinedocs/gdb/MiniDebugInfo.html#MiniDebugInfo).
There it says:
Keep all the function symbols not already in the dynamic symbol table.
That means the .symtab embedded inside the .gnu_debugdata does NOT contain the symbols from .dynsym. But in order to put a breakpoint on all symbols we need to load both. I hope this makes sense.
My other patch D66791 implements support for minidebuginfo, that's why I need this change.
Reviewers: labath, espindola, alexshap
Subscribers: JDevlieghere, emaste, arichardson, MaskRay, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67390
llvm-svn: 371599
This code is trying too hard and failing. Either the result of
gethostname() is canonical or it is not. If it is not, then trying to
canonicalize it is – for various reasons – a lost cause. For example, a
given machine might have multiple network interfaces with multiple
addresses per interface, each with a different canonical name.
Separably, the result of HostInfoPosix::GetHostname() and latency
thereof shouldn't depend on whether networking is up or down or what
network the machine happened to be attached to at any given moment (like
a laptop that travels between work and home).
https://reviews.llvm.org/D67230
llvm-svn: 371596
This patch adds basic support for DW_OP_convert[1] for integer
types. Recent versions of LLVM's optimizer may insert this opcode into
DWARF expressions. DW_OP_convert is effectively a type cast operation
that takes a reference to a base type DIE (or zero) and then casts the
value at the top of the DWARF stack to that type. Internally this
works by changing the bit size of the APInt that is used as backing
storage for LLDB's DWARF stack.
I managed to write a unit test for this by implementing a mock YAML
object file / module that takes debug info sections in yaml2obj
format.
[1] Typed DWARF stack. http://www.dwarfstd.org/ShowIssue.php?issue=140425.1
<rdar://problem/48167864>
Differential Revision: https://reviews.llvm.org/D67369
llvm-svn: 371532
This removes the CleanUp class and replaces its usages with llvm's
ScopeExit, which has similar semantics.
Differential revision: https://reviews.llvm.org/D67378
llvm-svn: 371474
ClangASTContext doesn't use m_persistent_variables in a way specific to
ClangPersistentVariables. Therefore, it should hold a unique pointer to
PersistentExpressionState instead of a ClangPersistentVariablesUP.
This also prevents you from pulling in a plugin header when including
ClangASTContext.h
Doing this exposed an implicit dependency in ObjCLanguage that was
corrected by including ClangModulesDeclVendor.h
llvm-svn: 371470
This is a fix for the issue described in r371144.
> On more than one occasion I've found this test got stuck during replay
> while waiting for a packet from debugserver when the debugger was in
> the process of being destroyed.
When the replay server is out of packets we should just disconnect so
the debugger doesn't have to do any cleanup that it wouldn't do during
capture.
llvm-svn: 371459
In April via r357829, Adrian unified timeouts across lldb and set the
default value high so that we wouldn't get timeouts on ASAN bots that
were running under load.
The library that the MacOSX SystemRuntime has functions that need
to take a lock, and if that lock is held already, those functions
will never complete; we're seeing the 15 second timeout being hit
with inferiors that are doing a lot of enqueuing and dequeuing of
libdispatch work items causing this deadlocking behavior.
This patch reverts to a very short timeout for these SystemRuntime
function calls, given the behavior of this library that they are
calling into. When lldb is built with AddressSanitizer enabled,
they will use the default 15 second timeout.
tl;dr: this reverts to the previous timeouts for these SystemRuntime
inf func calls.
<rdar://problem/54538149>
llvm-svn: 371280
Summary:
DumpDataExtractor uses ClangASTContext in order to get the proper llvm
fltSemantics for the type it needs so that it can dump floats in a more
precise way. However, there's no reason that this behavior needs to be
specific ClangASTContext. Instead, I think it makes sense to ask
TypeSystems for the float semantics for a type of a given size.
Differential Revision: https://reviews.llvm.org/D67239
llvm-svn: 371258
Summary:
This patch adds support of watchpoints to the old `ProcessWindows` plugin.
The `ProcessWindows` plugin uses the `RegisterContext` to set and reset
watchpoints. The `RegisterContext` has some interface to access watchpoints,
but it is very limited (e.g. it is impossible to retrieve the last triggered
watchpoint with it), that's why I have implemented a slightly different
interface in the `RegisterContextWindows`. Moreover, I have made the
`ProcessWindows` plugin responsible for search of a vacant watchpoint slot,
because watchpoints exist per-process (not per-thread), then we can place
the same watchpoint in the same slot in different threads. With this scheme
threads don't need to have their own watchpoint lists, and it simplifies
identifying of the last triggered watchpoint.
Reviewers: asmith, stella.stamenova, amccarth
Reviewed By: amccarth
Subscribers: labath, zturner, leonid.mashinskiy, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67168
llvm-svn: 371166
The bugreport command exists to create domain-specific bug reports.
Currently it has one implementation for filing bugs on the unwinder. As
far as we can tell, it has never been of use. Although not exactly the
same as the reproducers, it's a bit confusing to have two parallel
command trees for (kind of) the same thing.
Differential revision: https://reviews.llvm.org/D65469
llvm-svn: 371132
Summary:
With the XCode project gone, there doesn't seem to be anything setting
this macro anymore -- and the macro wasn't doing much anyway.
Reviewers: jingham, sgraenitz
Subscribers: emaste, lldb-commits
Differential Revision: https://reviews.llvm.org/D66742
llvm-svn: 371018
Summary:
This patch makes it possible to unwind via breakpad STACK WIN records.
It is "basic" because two important features are missing:
- support for the .raSearch keyword
- support for multiple STACK WIN records within a single function
Right now, we just reject the .raSearch records, and always pick the
first record for the whole function
SymbolFileBreakpad, and so I think it can serve as a good example of
what is needed of the symbol file and unwinding machinery to make this
work.
However, it is already useful for unwinding in some situations, and it
sets up the general framework for the parsing of these kinds of records,
which reduces the size of the followup patches implementing the two
other components.
Reviewers: amccarth, rnk, markmentovai
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D67067
llvm-svn: 371017
plugin.
Unfortunately the test is currently XFAILed because of missing changes
to the clang driver.
Differential Revision: https://reviews.llvm.org/D67124
llvm-svn: 370931
We were printing the start_addr field, which is not correct, as in this
branch we are processing the memory described by cur_range. Print that
instead.
Ideally, in particular this case, the error message would also say
something about not being able to disassemble due to not having found
the module from the core file, but that is not easy to do right now, so
I'm leaving that for another time.
llvm-svn: 370898
Michal Gorny