Summary:
The `CHECK: frame:py: None` seems to have been a typo, causing build bot failures:
```
# CHECK: frame:py: None
^
<stdin>:1:1: note: scanning from here
(lldb) command source -s 0 'E:/build_slave/lldb-x64-windows-ninja/build/tools/lldb\lit\lit-lldb-init'
^
<stdin>:23:1: note: possible intended match here
frame:py: No value
^
```
This update fixes the build bots.
--
Reviewers: bkramer
Reviewed By: bkramer
Differential Revision: https://reviews.llvm.org/D67702
llvm-svn: 372221
Summary:
Currently our expression evaluators only prints very basic errors that are not very useful when writing complex expressions.
For example, in the expression below the user made a type error, but it's not clear from the diagnostic what went wrong:
```
(lldb) expr printf("Modulos are:", foobar%mo1, foobar%mo2, foobar%mo3)
error: invalid operands to binary expression ('int' and 'double')
```
This patch enables full Clang diagnostics in our expression evaluator. After this patch the diagnostics for the expression look like this:
```
(lldb) expr printf("Modulos are:", foobar%mo1, foobar%mo2, foobar%mo3)
error: <user expression 1>:1:54: invalid operands to binary expression ('int' and 'float')
printf("Modulos are:", foobar%mo1, foobar%mo2, foobar%mo3)
~~~~~~^~~~
```
To make this possible, we now emulate a user expression file within our diagnostics. This prevents that the user is exposed to
our internal wrapper code we inject.
Note that the diagnostics that refer to declarations from the debug information (e.g. 'note' diagnostics pointing to a called function)
will not be improved by this as they don't have any source locations associated with them, so caret or line printing isn't possible.
We instead just suppress these diagnostics as we already do with warnings as they would otherwise just be a context message
without any context (and the original diagnostic in the user expression should be enough to explain the issue).
Fixes rdar://24306342
Reviewers: JDevlieghere, aprantl, shafik, #lldb
Reviewed By: JDevlieghere, #lldb
Subscribers: usaxena95, davide, jingham, aprantl, arphaman, kadircet, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D65646
llvm-svn: 372203
I don't know what the intent of parts of this test were. We set a
bunch of breakpoints and ran from one to the other, doing "self.runCmd("thread backtrace")"
then continuing to the next one. We didn't actually verify the contents of the backtrace,
nor that we hit the breakpoints we set in any particular order. The only actual test was
to run sel_getName at two of these stops.
So I reduced the test to just stopping at the places where we were actually going to run
an expression, and tested the expression.
llvm-svn: 372196
Summary: This way it can be overwritten when cross compiling.
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67641
llvm-svn: 372194
This test is about disassembling symbols in a framework without debug information.
So we don't need to run it once per debug info flavor.
llvm-svn: 372193
Jim pointed out that the LLDB global variables should only be available
in interactive mode. When used from a command for example, their values
might be stale or not at all what the user expects. Therefore we want to
explicitly make these variables unavailable.
Differential revision: https://reviews.llvm.org/D67685
llvm-svn: 372192
Summary:
This makes the input file for a new test added in r372060 directly
available in the Inputs subdirectory of the test dir.
Differential Revision: https://reviews.llvm.org/D67655
llvm-svn: 372112
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 test is failing on the Fedora bot (staging). Rather than failing
with an IndexError, we should trigger an assert and dump the log when
the regex doesn't match.
llvm-svn: 372052
Summary:
The path defined in CMakeLists.txt doesn't match the path generated in
our python script. This change fixes that.
LLVM_LIBRARY_OUTPUT_INTDIR is defined as:
${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/lib${LLVM_LIBDIR_SUFFIX})
On the other hand, the path of site-package is generaged in
get_framework_python_dir_windows() in finishSwigPythonLLDB.py as:
(Dispite its name, the function is used for everything other than xcode)
prefix/cmakeBuildConfiguration/distutils.sysconfig.get_python_lib()
From lldb/CMakeLists.txt, we can see that:
prefix=${CMAKE_BINARY_DIR},
cmakeBuildConfiguration=${CMAKE_CFG_INTDIR}
And from python source code, we can see get_python_lib() always returns
lib/pythonx.y/site-packages for posix, or Lib/site-packages for windows:
https://github.com/python/cpython/blob/3.8/Lib/distutils/sysconfig.py#L128
We should make them match each other.
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67583
llvm-svn: 372047
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
Summary:
These functions are only used in tests where we should test the actual flag values instead of counting all bits for an approximate check.
Also these popcount implementation aren't very efficient and doesn't seem to be optimised to anything fast.
Reviewers: davide, JDevlieghere
Reviewed By: davide, JDevlieghere
Subscribers: abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67540
llvm-svn: 372018
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
This ensures that if the assertion fails we dump the log content. This
should help me investigate what the output looks like on Windows, where
the test is failing.
llvm-svn: 371899
The new centralized way of doing API logging through the reproducer
macros is lacking a way to easily correlate instances of API objects.
Logging the this pointer makes that significantly easier. For methods
this is now always passed as the first argument, similar to the self
argument in Python.
This patch also adds a test case for API logging, which uncovered that
we were not quoting strings.
Differential revision: https://reviews.llvm.org/D67538
llvm-svn: 371885
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
These tests were temporarily missing when the big Makefile
simplification patch landed, so this just applies the same change
to these tests.
llvm-svn: 371738
After reverting the deletion of the functionalities/breakpoint tests,
we now have some tests twice in the test/ folder which breaks dotest:
* commands/breakpoint/basic
* functionalities/breakpoint/breakpoint_command
After looking over these tests, I think it makes sense to only
keep the original functionalities/ folder. The commands/breakpoint/basic
test are not exclusively testing the breakpoint command itself, so
they shouldn't be in commands/ in the first place. Note that these
folders have identical contents (beside small adjustments regarding
the Makefile which landed after the restructuring).
llvm-svn: 371734
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
It seems when I restructured the test folders the functionalities/breakpoint
was deleted. This just reverts this change and re-adds the tests.
llvm-svn: 371512
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
Modifying the interpreter settings is tricky because they don't take
effect until we create a new command interpreter, which should be merely
an implementation detail. This leads to confusing and unexpected
scenarios.
This adds a test cases with FIXMEs for some of the odd scenarios I
encountered. I didn't XFAIL the test because I don't think there's a way
to get an unexpected PASS if any of the commands succeeds and splitting
up the file in multiple tests seems excessive.
llvm-svn: 371259
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
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. For some reason it's more prevalent on the
downstream Swift fork. Adding a cont mitigates the problem while I
investigate.
llvm-svn: 371144
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
[Patch by Leonid Mashinskiy]
Visual Studio CMake generator is multi-target and does not define
CMAKE_BUILD_TYPE, so Debug build on VS was failing due selection of release
python library. This patch reverts back some of latest changes and fixes
building by raw VS using CMake expression generators.
Differential Revision: https://reviews.llvm.org/D66994
llvm-svn: 371090
I'm still unable to reproduce this locally, so let's see if this
is enough to make the bots happy. The missing dimension parameter
seems to be the biggest difference between these tests and
TestIOHandlerCompletion.py which runs just fine on the same bot,
so that's the motivation for trying this out.
llvm-svn: 371077
This appears to be a really ancient way of running the test suite. It
is also completely disfunctional now, and probably has been for a long
time.
llvm-svn: 371020
Summary:
In r367234 we introduced a central place to hold the set up commands for
the various ways we have of launching lldb. However, a number of
commands still remained outside of that.
This patch moves the remaining set up commands into this function, which
allows us to remove manual clang module path setting code in
TestBatchMode.
One unfortunate victim of this approach is TestSTTYBeforeAndAfter which,
due to how it launches lldb (pexpect->expect->lldb), fails get the
quoting right. It would be possible to fix the quoting there, it would be a bit
icky, and none of the commands in this list are really relevant for what this
test is doing, so I just remove the commands outright.
Reviewers: JDevlieghere, jankratochvil
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D67173
llvm-svn: 371019
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
This reverts my change to pseudo_barrier.h which isn't necessary anymore
after Fred's fix to debugserver and caused TestThreadStepOut to fail.
llvm-svn: 370963
Python 3 iteration calls the next() method instead of next() and
value_iter only implemented the Python 2 version.
Differential revision: https://reviews.llvm.org/D67184
llvm-svn: 370954
Python 3 calls __bool__() instead of __len__() and lldb.value only
implemented the __len__ method. This adds the __bool__() implementation.
Differential revision: https://reviews.llvm.org/D67183
llvm-svn: 370953
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
The flakiness on our local machines seems to come for a race in the kernel
between task_suspend and the creation of the Mach exceptions for the threads
that hit breakpoints. The debugserver code is written with the assumption
that the kernel will be able to provide us with all the exceptions for a
given task once task_suspend returns. On machines with higher core counts,
this seems not to be the case. The first batch of exceptions we get after
task_suspend does not contain exceptions for all the threads that have hit
a breakpoint, thus they get misreprorted in the first stop packet.
Adding a 1ms timeout to the call that retrieves the batch of exceptions
seems to workaround the issue reliably on our machines, and it shoulnd't
impact standard debugging scenarios too much (a stop will incur an additional
1ms delay). We'll be talking to the kernel team to figure out the right
contract for those APIs.
This patch also reverts part of Jonas' previous workaround for the
issue (r370785).
llvm-svn: 370916
Krasimir Georgiev