2485 Commits

Author SHA1 Message Date
Jonas Devlieghere
5f775d2912 [JSON] Don't wrap json::Array in a value (NFC)
There's no need to wrap the just-constructed json::Array in a
json::Value, we can just return that and pass ownership to the
raw_ostream.

llvm-svn: 373656
2019-10-03 20:10:56 +00:00
Pavel Labath
ecd849ed56 Fix a use-after-free in GDBRemoteCommunicationServerLLGS
Although it's called "GetString", StreamString::GetString actually
returns a StringRef. Creating a json object with a StringRef does not
make a copy, which means the StringRef will be dangling as soon as the
underlying stream is destroyed. Add a .str() to force the json object to
hold a copy of the string.

This fixes nearly every test on linux.

llvm-svn: 373572
2019-10-03 07:59:26 +00:00
Lawrence D'Anna
f913fd6eb0 factor out an abstract base class for File
Summary:
This patch factors out File as an abstract base
class and moves most of its actual functionality into
a subclass called NativeFile.   In the next patch,
I'm going to be adding subclasses of File that
don't necessarily have any connection to actual OS files,
so they will not inherit from NativeFile.

This patch was split out as a prerequisite for
https://reviews.llvm.org/D68188

Reviewers: JDevlieghere, jasonmolenda, labath

Reviewed By: labath

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D68317

llvm-svn: 373564
2019-10-03 04:31:46 +00:00
Davide Italiano
293ec1e16a [RegisterContextDarwin_arm64] Include the headers for getsysctlbyname.
This code is only used under __arm64__, use the correct guard.

<rdar://problem/55916729>

llvm-svn: 373509
2019-10-02 19:20:21 +00:00
Jonas Devlieghere
4f8151e62e [JSON] Use LLVM's library for encoding JSON in GDBRemoteCommunicationServerCommon
This patch replaces the LLDB's JSON implementation with the one from
LLVM in GDBRemoteCommunicationServerCommon.

Differential revision: https://reviews.llvm.org/D68304

llvm-svn: 373500
2019-10-02 18:02:32 +00:00
Jonas Devlieghere
7cb720dda0 [JSON] Use LLVM's library for encoding JSON in GDBRemoteCommunicationServerPlatform
This patch replaces the LLDB's JSON implementation with the one from
LLVM in GDBRemoteCommunicationServerPlatform.

Differential revision: https://reviews.llvm.org/D68302

llvm-svn: 373499
2019-10-02 18:02:29 +00:00
Jonas Devlieghere
2a5a906753 [JSON] Use LLVM's library for encoding JSON in GDBRemoteCommunicationClient
This patch replaces the LLDB's JSON implementation with the one from
LLVM in GDBRemoteCommunicationClient.

Differential revision: https://reviews.llvm.org/D68301

llvm-svn: 373498
2019-10-02 18:02:26 +00:00
Jonas Devlieghere
9beb45671b [JSON] Use LLVM's library for encoding JSON in GDBRemoteCommunicationServerLLGS
This patch replaces the LLDB's JSON implementation with the one from
LLVM in GDBRemoteCommunicationServerLLGS.

Differential revision: https://reviews.llvm.org/D68299

llvm-svn: 373497
2019-10-02 18:02:23 +00:00
Jonas Devlieghere
2783d81791 [JSON] Use LLVM's library for encoding JSON in StructuredData
This patch replaces the hand-rolled JSON emission in StructuredData with
LLVM's JSON library.

Differential revision: https://reviews.llvm.org/D68248

llvm-svn: 373359
2019-10-01 17:41:48 +00:00
Aleksandr Urakov
5b5274eaf8 [Windows] Added support of watchpoints to NativeProcessWindows
Summary: This patch adds support of watchpoints to the new `NativeProcessWindows` plugin. The same tests as in D67168 pass with these changes when the old plugin is turned off, so they will cover this functionality when the old plugin is gone.

Reviewers: asmith, amccarth, stella.stamenova, labath

Reviewed By: labath

Subscribers: labath, jfb, JDevlieghere, lldb-commits, leonid.mashinskiy

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D67222

llvm-svn: 373300
2019-10-01 05:52:16 +00:00
Pavel Labath
6f23a68a84 Use llvm for dumping DWARF expressions
Summary:
It uses the new ability of ABI plugins to vend llvm::MCRegisterInfo
structs (which is what is needed to turn dwarf register numbers into
strings).

Reviewers: JDevlieghere, aprantl, jasonmolenda

Subscribers: tatyana-krasnukha, lldb-commits

Differential Revision: https://reviews.llvm.org/D67966

llvm-svn: 373208
2019-09-30 13:44:17 +00:00
Pavel Labath
a8b284eeec Unwind: Add a stack scanning mechanism to support win32 unwinding
Summary:
Windows unwinding is weird. The unwind rules do not (always) describe
the precise layout of the stack, but rather expect the debugger to scan
the stack for something which looks like a plausible return address, and
the unwind based on that. The reason this works somewhat reliably is
because the the unwinder also has access to the frame sizes of the
functions on the stack. This allows it (in most cases) to skip function
pointers in local variables or function arguments, which could otherwise
be mistaken for return addresses.

Implementing this kind of unwind mechanism in lldb was a bit challenging
because we expect to be able to statically describe (in the UnwindPlan)
structure, the layout of the stack for any given instruction. Giving a
precise desription of this is not possible, because it requires
correlating information from two functions -- the pushed arguments to a
function are considered a part of the callers stack frame, and their
size needs to be considered when unwinding the caller, but they are only
present in the unwind entry of the callee. The callee may end up being
in a completely different module, or it may not even be possible to
determine it statically (indirect calls).

This patch implements this functionality by introducing a couple of new
APIs:
SymbolFile::GetParameterStackSize - return the amount of stack space
  taken up by parameters of this function.
SymbolFile::GetOwnFrameSize - the size of this function's frame. This
  excludes the parameters, but includes stuff like local variables and
  spilled registers.

These functions are then used by the unwinder to compute the estimated
location of the return address. This address is not always exact,
because the stack may contain some additional values -- for instance, if
we're getting ready to call a function then the stack will also contain
partially set up arguments, but we will not know their size because we
haven't called the function yet. For this reason the unwinder will crawl
up the stack from the return address position, and look for something
that looks like a possible return address. Currently, we assume that
something is a valid return address if it ends up pointing to an
executable section.

All of this logic kicks in when the UnwindPlan sets the value of CFA as
"isHeuristicallyDetected", which is also the final new API here. Right
now, only SymbolFileBreakpad implements these APIs, but in the future
SymbolFilePDB will use them too.

Differential Revision: https://reviews.llvm.org/D66638

llvm-svn: 373072
2019-09-27 12:10:06 +00:00
Lawrence D'Anna
2fce1137c7 Convert FileSystem::Open() to return Expected<FileUP>
Summary:
This patch converts FileSystem::Open from this prototype:

Status
Open(File &File, const FileSpec &file_spec, ...);

to this one:

llvm::Expected<std::unique_ptr<File>>
Open(const FileSpec &file_spec, ...);

This is beneficial on its own, as llvm::Expected is a more modern
and recommended error type than Status.  It is also a necessary step
towards https://reviews.llvm.org/D67891, and further developments
for lldb_private::File.

Reviewers: JDevlieghere, jasonmolenda, labath

Reviewed By: labath

Subscribers: mgorny, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D67996

llvm-svn: 373003
2019-09-26 17:54:59 +00:00
Tatyana Krasnukha
5a4355324e [NFC] Fix typo in the "kind" description for the software single-step breakpoint
llvm-svn: 372763
2019-09-24 14:24:52 +00:00
Michal Gorny
a292a4943b [lldb] [Process/NetBSD] Fix handling LLDB_INVALID_SIGNAL_NUMBER
Fix NativeProcessNetBSD::Resume() to handle LLDB_INVALID_SIGNAL_NUMBER
correctly.  Fixes breakage caused by r372090 and r372300.  I have major
rewrite of that function pending; however, the fixes to gdb-remote
were committed prior to that.

llvm-svn: 372755
2019-09-24 13:41:54 +00:00
Martin Storsjo
e37b882421 [LLDB] Fix typo in RegisterContextDarwin_arm64
In these cases, the register number should be calculated from
fpu_d0, not fpu_s0.

Differential Revision: https://reviews.llvm.org/D67892

llvm-svn: 372738
2019-09-24 12:20:21 +00:00
Martin Storsjo
02dddfd2ae [LLDB] [Windows] Add missing ifdefs to fix building for non-x86 architectures
While debugging on those architectures might not be supported yet,
the generic code should still be buildable. This file accesses x86
specific fields in the CONTEXT struct.

Differential Revision: https://reviews.llvm.org/D67911

llvm-svn: 372699
2019-09-24 08:39:06 +00:00
Jonas Devlieghere
948786c929 File::SetDescriptor() should require options
lvm_private::File::GetStream() can fail if m_options == 0

It's not clear from the header a File created with a descriptor will be
not be usable by many parts of LLDB unless SetOptions is also called,
but it is.

This is because those parts of LLDB rely on GetStream() to use the
file, and that in turn relies on calling fdopen on the descriptor. When
calling fdopen, GetStream relies on m_options to determine the access
mode. If m_options has never been set, GetStream() will fail.

This patch adds options as a required argument to File::SetDescriptor
and the corresponding constructor.

Patch by: Lawrence D'Anna

Differential revision: https://reviews.llvm.org/D67792

llvm-svn: 372652
2019-09-23 20:36:46 +00:00
Martin Storsjo
ed78dc8e43 [LLDB] Use SetErrorStringWithFormatv for cases that use LLVM style format strings
SetErrorStringWithFormat only supports normal printf style format
strings.

Differential Revision: https://reviews.llvm.org/D67862

llvm-svn: 372485
2019-09-21 19:10:00 +00:00
Martin Storsjo
5c38730dbd [LLDB] Use LLVM_FALLTHROUGH instead of a custom comment
This fixes a warning when built with Clang in MinGW mode.

Differential Revision: https://reviews.llvm.org/D67860

llvm-svn: 372484
2019-09-21 19:09:54 +00:00
Martin Storsjo
2e25c44dc3 [LLDB] Check for the GCC/MinGW compatible arch defines for windows, in addition to MSVC defines
This matches how it is done in all other similar ifdefs throughout
lldb.

Differential Revision: https://reviews.llvm.org/D67858

llvm-svn: 372483
2019-09-21 19:09:49 +00:00
Martin Storsjo
f4deacf995 [LLDB] Fix compilation for MinGW, remove redundant class name on inline member
This fixes build errors like these:

NativeRegisterContextWindows.h:22:33: error: extra qualification on member 'NativeRegisterContextWindows'
  NativeRegisterContextWindows::NativeRegisterContextWindows(
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^

Differential Revision: https://reviews.llvm.org/D67856

llvm-svn: 372482
2019-09-21 19:09:43 +00:00
Michal Gorny
c36b0bf310 [lldb] [Process/gdb-remote] Correct more missing LLDB_INVALID_SIGNAL_NUMBER
Correct more uses of 0 instead of LLDB_INVALID_SIGNAL_NUMBER.

Differential Revision: https://reviews.llvm.org/D67727

llvm-svn: 372300
2019-09-19 05:49:14 +00:00
Michal Gorny
e4d25e9e16 [lldb] [Process/gdb-remote] Fix defaulting signal to invalid in action list
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
2019-09-17 09:31:00 +00:00
Jonas Devlieghere
4e053ff1d1 [NFC] Move dumping into GDBRemotePacket
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
2019-09-16 20:02:57 +00:00
Jonas Devlieghere
ff5225bfb6 [Reproducer] Move GDB Remote Packet into Utility. (NFC)
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
2019-09-13 23:14:10 +00:00
Alex Langford
5b2b38e053 [Target] Move InferiorCall to Process
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
2019-09-13 00:02:05 +00:00
Jonas Devlieghere
bcc24e46ba [Reproducer] Move GDB Remote Provider into Reproducer (NFC)
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
2019-09-11 23:15:12 +00:00
Alex Langford
1b385a1802 [Plugins/Process] Remove direct use of ClangASTContext from InferiorCallPOSIX
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
2019-09-11 20:36:28 +00:00
Jonas Devlieghere
e0ea8d87eb [Utility] Replace lldb_private::CleanUp by llvm::scope_exit
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
2019-09-10 00:20:50 +00:00
Jonas Devlieghere
9b961cc604 [Reproducer] Disconnect when the replay server is out of packets.
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
2019-09-09 22:05:48 +00:00
Greg Clayton
4f68c226a5 Fix ELF core file memory reading for PT_LOAD program headers with no p_filesz
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
2019-09-09 21:45:49 +00:00
Aleksandr Urakov
6179c0eb0d [Windows] Add support of watchpoints to ProcessWindows
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
2019-09-06 05:37:03 +00:00
Pavel Labath
7790858b00 Obliterate LLDB_CONFIGURATION_BUILDANDINTEGRATION
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
2019-09-05 07:09:31 +00:00
Adrian Prantl
2461061168 Upstream macCatalyst support in debugserver and the macOS dynamic loader
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
2019-09-04 17:23:15 +00:00
Pavel Labath
3f3673ead9 NativeProcessLinux: Remove some register context boilerplate
Summary:
This patch follows the spirit of D63594, and removes some null checks
for things which should be operating invariants. Specifically
{Read,Write}[GF]PR now no longer check whether the supplied buffers are
null, because they never are. After this, the Do*** versions of these
function no longer serve any purpose and are inlined into their callers.

Other cleanups are possible here too, but I am taking this one step at a
time because this involves a lot of architecture-specific code, which I
don't have the hardware to test on (I did do a build-test though).

Reviewers: mgorny, jankratochvil, omjavaid, alexandreyy, uweigand

Subscribers: nemanjai, javed.absar, kbarton, lldb-commits

Differential Revision: https://reviews.llvm.org/D66744

llvm-svn: 370653
2019-09-02 12:50:18 +00:00
Omair Javaid
1da33fd4ef [ARM64] Simplify RegisterInfos_arm64.h with macro based RegisterInfo array
This patches paves way for upcoming SVE RegisterInfo definitions. This is cosmetic change which allows us to define ARM64 RegisterInfo using macros.

In future we ll have define two different RegisterInfos to choose between SVE vs non-SVE RegisterInfo with decision being made at thread creation.

Differential Revision: https://reviews.llvm.org/D66934

llvm-svn: 370644
2019-09-02 11:53:29 +00:00
Tatyana Krasnukha
900f9ba217 [lldb] Fix x86 compilation
Differential Revision: https://reviews.llvm.org/D66655

Patch by Leonid Mashinskiy

llvm-svn: 370078
2019-08-27 17:22:03 +00:00
Pavel Labath
e588b8b664 DWARFExpression: Simplify class interface
Summary:
The DWARFExpression methods have a lot of arguments. This removes two of
them by removing the ability to slice the expression via two offset+size
parameters. This is a functionality that it is not always needed, and
when it is, we already have a different handy way of slicing a data
extractor which we can use instead.

Reviewers: JDevlieghere, clayborg

Subscribers: aprantl, lldb-commits

Differential Revision: https://reviews.llvm.org/D66745

llvm-svn: 370027
2019-08-27 07:49:41 +00:00
Pavel Labath
341df3f13a Really fix the type mismatch error in GDBRemoteCommunicationServerCommon
My previous attempt in attempt in r369904 actually broke the 32bit build
because File::Read expects to take a reference to size_t. Fix the
warning by using SIZE_MAX to denote failure instead.

llvm-svn: 369910
2019-08-26 13:56:33 +00:00
Tatyana Krasnukha
55aafa35ea [ProcessWindows] Remove equivalent macros
llvm-svn: 369908
2019-08-26 13:35:59 +00:00
Pavel Labath
27f56c1200 Fix a type mismatch error in GDBRemoteCommunicationServerCommon
GetU64 returns a uint64_t. Don't store it in size_t as that is only
32-bit on 32-bit platforms.

llvm-svn: 369904
2019-08-26 12:42:28 +00:00
Saleem Abdulrasool
e7823a5316 Windows: explicitly cast constants to DWORD
STATUS_SINGLE_STEP and STATUS_BREAKPOINT are defined as 0x8------ which
is negative and thus can't be implicitly narrowed to a DWORD which is
unsigned.  The value is defined differently across winnt.h and ntstatus.h.

Patch by Gwen Mittertreiner!

llvm-svn: 369788
2019-08-23 17:58:53 +00:00
Pavel Labath
d139e8838a Recommit "Minidump/Windows: Fix module lookup""
This recommits r368416, which was reverted in r368838 because of test
failures under ASAN. These have been dealt with by llvm r369370.

The original commit message was:
When opening a minidump, we were failing to find an executable because
we were searching for i386-unknown-windows, whereas we recognize the
pe/coff files as i386-pc-windows. This fixes the triple computation code
in the minidump parser to match pe/coff, and adds an appropriate test.

NB: I'm not sure setting the vendor to "pc" is really correct for
arm(64) windows, but right now that seems to match what we do in the
pe/coff case (ArchSpec.cpp:935).

Reviewers: clayborg, amccarth

Subscribers: javed.absar, kristof.beyls, rnk, markmentovai, lldb-commits

Differential Revision: https://reviews.llvm.org/D65955

llvm-svn: 369523
2019-08-21 13:20:25 +00:00
Jonas Devlieghere
d35b42f20a [NFC] Return llvm::StringRef from StringExtractor::GetStringRef.
This patch removes the two variant of StringExtractor::GetStringRef that
return (non-)const references to std::string. The non-const one was
being abused to reinitialize the StringExtractor and its uses are
replaced by calls to the copy asignment operator. The const variant was
refactored to return an actual llvm::StringRef.

llvm-svn: 369493
2019-08-21 04:55:56 +00:00
Jan Kratochvil
f9d90bc5f6 [lldb] D66174 RegularExpression cleanup
I find as a good cleanup to drop the Compile method. As I do not find TIMTOWTDI
as an advantage and there is already constructor parameter to compile the
regex.

Differential Revision: https://reviews.llvm.org/D66392

llvm-svn: 369352
2019-08-20 09:24:20 +00:00
Saleem Abdulrasool
2e8b57558d Windows: Include "windows" Instead of "Windows"
The actual include directory is lldb/Host/windows not
lldb/Host/Windows which breaks on case sensitive file systems

Patch by Gwen Mittertreiner!

llvm-svn: 369307
2019-08-19 22:45:01 +00:00
Jonas Devlieghere
3af3f1e8e2 [Utility] Reimplement RegularExpression on top of llvm::Regex
Originally I wanted to remove the RegularExpression class in Utility and
replace it with llvm::Regex. However, during that transition I noticed
that there are several places where need the regular expression string.
So instead I propose to keep the RegularExpression class and make it a
thin wrapper around llvm::Regex.

This patch also removes the workaround for empty regular expressions.
The result is that we are now (more or less) POSIX conformant.

Differential revision: https://reviews.llvm.org/D66174

llvm-svn: 369153
2019-08-16 21:25:36 +00:00
Jonas Devlieghere
a8f3ae7c9c [LLDB] Migrate llvm::make_unique to std::make_unique
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.

Differential revision: https://reviews.llvm.org/D66259

llvm-svn: 368933
2019-08-14 22:19:23 +00:00
Pavel Labath
b8ee0dd723 Revert "Minidump/Windows: Fix module lookup"
Although there is nothing wrong with this patch, the test added here
uncovers a problem in other parts of the code which cause the test to
fail when running under asan. Reverting the patch until I can fix the
underlying issue(s).

This reverts commit r368416.

llvm-svn: 368838
2019-08-14 12:26:51 +00:00