| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 371784
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 371688
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 371667
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
This reverts commit 3a4781bbf4f39a25562b4c61c9a9ab2483a96b41.
llvm-svn: 371625
|
|
|
|
|
|
| |
This reverts commit 813f05915d29904878d926f9849ca3dbe78096af.
llvm-svn: 371624
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 371618
|
|
|
|
| |
llvm-svn: 371614
|
|
|
|
| |
llvm-svn: 371600
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 371583
|
|
|
|
| |
llvm-svn: 371582
|
|
|
|
|
|
|
| |
The comparison against LOG_MEMORY shortcut all the LOG_MEMORY_*
log channels. It has to come last.
llvm-svn: 371560
|
|
|
|
| |
llvm-svn: 371544
|
|
|
|
|
|
|
| |
Finding the call edge in a function which corresponds to a particular
return address is a generic/useful operation.
llvm-svn: 371543
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 371491
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 371472
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ClangPersistentVariables
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 should no longer be necessary after r371459.
llvm-svn: 371460
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prior to this fix, ELF files might contain PT_LOAD program headers that had a valid p_vaddr, and a valid file p_offset, but the p_filesz would be zero. For example in llvm-project/lldb/test/testcases/functionalities/postmortem/elf-core/thread_crash/linux-i386.core we see:
Program Headers:
Index p_type p_flags p_offset p_vaddr p_paddr p_filesz p_memsz p_align
======= ---------------- ---------- ------------------ ------------------ ------------------ ------------------ ------------------ ------------------
[ 0] PT_NOTE 0x00000000 0x0000000000000474 0x0000000000000000 0x0000000000000000 0x0000000000001940 0x0000000000000000 0x0000000000000000
[ 1] PT_LOAD 0x00000005 0x0000000000002000 0x0000000008048000 0x0000000000000000 0x0000000000000000 0x0000000000003000 0x0000000000001000
[ 2] PT_LOAD 0x00000004 0x0000000000002000 0x000000000804b000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000
[ 3] PT_LOAD 0x00000006 0x0000000000002000 0x000000000804c000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000
[ 4] PT_LOAD 0x00000006 0x0000000000002000 0x0000000009036000 0x0000000000000000 0x0000000000000000 0x0000000000025000 0x0000000000001000
[ 5] PT_LOAD 0x00000000 0x0000000000002000 0x00000000f63a1000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000
[ 6] PT_LOAD 0x00000006 0x0000000000002000 0x00000000f63a2000 0x0000000000000000 0x0000000000000000 0x0000000000800000 0x0000000000001000
[ 7] PT_LOAD 0x00000000 0x0000000000002000 0x00000000f6ba2000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000
[ 8] PT_LOAD 0x00000006 0x0000000000002000 0x00000000f6ba3000 0x0000000000000000 0x0000000000000000 0x0000000000804000 0x0000000000001000
[ 9] PT_LOAD 0x00000005 0x0000000000002000 0x00000000f73a7000 0x0000000000000000 0x0000000000000000 0x00000000001b1000 0x0000000000001000
[ 10] PT_LOAD 0x00000004 0x0000000000002000 0x00000000f7558000 0x0000000000000000 0x0000000000000000 0x0000000000002000 0x0000000000001000
[ 11] PT_LOAD 0x00000006 0x0000000000002000 0x00000000f755a000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000
[ 12] PT_LOAD 0x00000006 0x0000000000002000 0x00000000f755b000 0x0000000000000000 0x0000000000000000 0x0000000000003000 0x0000000000001000
[ 13] PT_LOAD 0x00000005 0x0000000000002000 0x00000000f755e000 0x0000000000000000 0x0000000000000000 0x0000000000019000 0x0000000000001000
[ 14] PT_LOAD 0x00000004 0x0000000000002000 0x00000000f7577000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000
[ 15] PT_LOAD 0x00000006 0x0000000000002000 0x00000000f7578000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000
[ 16] PT_LOAD 0x00000006 0x0000000000002000 0x00000000f7579000 0x0000000000000000 0x0000000000000000 0x0000000000002000 0x0000000000001000
[ 17] PT_LOAD 0x00000005 0x0000000000002000 0x00000000f757b000 0x0000000000000000 0x0000000000000000 0x000000000001c000 0x0000000000001000
[ 18] PT_LOAD 0x00000004 0x0000000000002000 0x00000000f7597000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000
[ 19] PT_LOAD 0x00000006 0x0000000000002000 0x00000000f7598000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000
[ 20] PT_LOAD 0x00000005 0x0000000000002000 0x00000000f7599000 0x0000000000000000 0x0000000000000000 0x0000000000053000 0x0000000000001000
[ 21] PT_LOAD 0x00000004 0x0000000000002000 0x00000000f75ec000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000
[ 22] PT_LOAD 0x00000006 0x0000000000002000 0x00000000f75ed000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000
[ 23] PT_LOAD 0x00000005 0x0000000000002000 0x00000000f75ee000 0x0000000000000000 0x0000000000000000 0x0000000000176000 0x0000000000001000
[ 24] PT_LOAD 0x00000004 0x0000000000002000 0x00000000f7764000 0x0000000000000000 0x0000000000000000 0x0000000000006000 0x0000000000001000
[ 25] PT_LOAD 0x00000006 0x0000000000002000 0x00000000f776a000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000
[ 26] PT_LOAD 0x00000006 0x0000000000002000 0x00000000f776b000 0x0000000000000000 0x0000000000000000 0x0000000000003000 0x0000000000001000
[ 27] PT_LOAD 0x00000006 0x0000000000002000 0x00000000f778a000 0x0000000000000000 0x0000000000000000 0x0000000000002000 0x0000000000001000
[ 28] PT_LOAD 0x00000004 0x0000000000002000 0x00000000f778c000 0x0000000000000000 0x0000000000002000 0x0000000000002000 0x0000000000001000
[ 29] PT_LOAD 0x00000005 0x0000000000004000 0x00000000f778e000 0x0000000000000000 0x0000000000002000 0x0000000000002000 0x0000000000001000
[ 30] PT_LOAD 0x00000005 0x0000000000006000 0x00000000f7790000 0x0000000000000000 0x0000000000000000 0x0000000000022000 0x0000000000001000
[ 31] PT_LOAD 0x00000004 0x0000000000006000 0x00000000f77b3000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000
[ 32] PT_LOAD 0x00000006 0x0000000000006000 0x00000000f77b4000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000
[ 33] PT_LOAD 0x00000006 0x0000000000006000 0x00000000ffa25000 0x0000000000000000 0x0000000000000000 0x0000000000022000 0x0000000000001000
Prior to this fix if users tried to read memory from one of these addresses like 0x8048000, they would end up incorrectly reading from the next memory region that actually had a p_filesz which would be 0x00000000f778c000 in this case. This fix correctly doesn't include program headers with zero p_filesz in the ProcessELFCore::m_core_aranges that is used to read memory. I found two cores files that have this same issue and added tests.
Differential Revision: https://reviews.llvm.org/D67370
llvm-svn: 371457
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: zturner, emaste
Reviewed By: emaste
Differential Revision: https://reviews.llvm.org/D46518
llvm-svn: 371417
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 371234
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D67230
llvm-svn: 371195
|
|
|
|
|
|
| |
This just reimplemented llvm::StringRef::[r/l]trim().
llvm-svn: 371181
|
|
|
|
| |
llvm-svn: 371180
|
|
|
|
| |
llvm-svn: 371176
|
|
|
|
| |
llvm-svn: 371172
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
generator
[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
|
|
|
|
|
|
| |
We should wait on the GUI to exit before tearing down the test.
llvm-svn: 371028
|
|
|
|
|
|
|
|
| |
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
|