Commit Graph

1226 Commits

Author SHA1 Message Date
Benjamin Kramer f15014ff54 Revert "Rename llvm::array_lengthof into llvm::size to match std::size from C++17"
This reverts commit ef82063207.

- It conflicts with the existing llvm::size in STLExtras, which will now
  never be called.
- Calling it without llvm:: breaks C++17 compat
2022-01-26 16:55:53 +01:00
serge-sans-paille ef82063207 Rename llvm::array_lengthof into llvm::size to match std::size from C++17
As a conquence move llvm::array_lengthof from STLExtras.h to
STLForwardCompat.h (which is included by STLExtras.h so no build
breakage expected).
2022-01-26 16:17:45 +01:00
David Spickett 37c4bd0fdb [lldb] Add MemoryTagMap class
The tag map holds a sparse set of memory tags and allows
you to query ranges for tags.

Granules that do not have tags will be set to llvm::None.
to keep the ordering intact. If there are no tags for the
requested range we'll just return an empty result so that
callers don't need to check that all values are llvm::None.

This will be combined with MemoryTagManager's MakeTaggedRanges:
* MakeTaggedRanges
* Read from all those ranges
* Insert the results into the tag map
* Give the tag map to whatever needs to print tags

Which in this case will be "memory read"/DumpDataExtractor.

Reviewed By: JDevlieghere

Differential Revision: https://reviews.llvm.org/D112825
2022-01-26 13:55:48 +00:00
David Spickett ee0c3820f8 [lldb][AArch64] Add MakeTaggedRanges to MemoryTagManager
This is to be used when you want to know what subranges
of a larger range have memory tagging. Like MakeTaggedRange
but memory without tags is skipped and you get a list of ranges back.

Will be used later by DumpDataExtractor to show memory tags.

MakeTaggedRanges assumes that the memory regions it is
given are sorted in ascending order and do not overlap.
For the current use case where you get regions from
GetMemoryRegions and are on some Linux like OS, this is
reasonable to assume.

I've used asserts to check those conditions. In future
any API binding will check them up front to prevent a crash.

Reviewed By: omjavaid

Differential Revision: https://reviews.llvm.org/D112824
2022-01-26 11:30:10 +00:00
Pavel Labath 0f08db66db [lldb] Make logging machinery type-safe
This patch makes use of c++ type checking and scoped enums to make
logging statements shorter and harder to misuse.

Defines like LIBLLDB_LOG_PROCESS are replaces with LLDBLog::Process.
Because it now carries type information we do not need to worry about
matching a specific enum value with the right getter function -- the
compiler will now do that for us.

The main entry point for the logging machinery becomes the GetLog
(template) function, which will obtain the correct Log object based on
the enum type. It achieves this through another template function
(LogChannelFor<T>), which must be specialized for each type, and should
return the appropriate channel object.

This patch also removes the ability to log a message if multiple
categories are enabled simultaneously as it was unused and confusing.

This patch does not actually remove any of the existing interfaces. The
defines and log retrieval functions are left around as wrappers around
the new interfaces. They will be removed in follow-up patch.

Differential Revision: https://reviews.llvm.org/D117490
2022-01-25 12:13:49 +01:00
serge-sans-paille 25e8f5f827 Add missing STLExtras.h include from lldb/unittests/TestingSupport/MockTildeExpressionResolver.cpp 2022-01-24 15:03:11 +01:00
David Spickett 585abe3ba5 [lldb] Rename MemoryTagManager RemoveNonAddressBits to RemoveTagBits
This better describes the intent of the method. Which for AArch64
is removing the top byte which includes the memory tags.

It does not include pointer signatures, for those we need to use
the ABI plugin. The rename makes this a little more clear.

It's a bit awkward that the memory tag manager is removing the whole
top byte not just the memory tags but it's an improvement for now.

Reviewed By: omjavaid

Differential Revision: https://reviews.llvm.org/D117671
2022-01-20 10:47:05 +00:00
Jonas Devlieghere eb5c0ea681 [lldb] Initialize Python exactly once
We got a few crash reports that showed LLDB initializing Python on two
separate threads. Make sure Python is initialized exactly once.

rdar://87287005

Differential revision: https://reviews.llvm.org/D117601
2022-01-19 09:56:55 -08:00
Pavel Labath 7f4d66f23e [lldb] Delete TestStopReplyContainsThreadPcs
This was meant to be a replacement for the lldb-server sub-test suite of
the API tests, but it never got off the ground and it's making the
windows bot flaky.

Deleting it does not reduce test coverage as the original api test is
still around.
2022-01-18 14:17:33 +01:00
Pavel Labath 04f13da677 [lldb] Fix compiler warning in CommunicationTest
"0x80 changes value when converted to char"
2022-01-18 10:31:37 +01:00
Pavel Labath c154f397ee [lldb/python] Use PythonObject in LLDBSwigPython functions
Return our PythonObject wrappers instead of raw PyObjects (obfuscated as
void *). This ensures that ownership (reference counts) of python
objects is automatically tracked.

Differential Revision: https://reviews.llvm.org/D117462
2022-01-18 10:28:58 +01:00
Jonas Devlieghere ff85dcb1c5 [lldb] Remove PlatformDarwin::GetCompatibleArch helper
This also removes the corresponding unit tests. I wrote them to sanity
check my original refactoring and checked them in because why not. The
current implementation, without the added complexity of indices, is
simple enough that we can do without it.
2022-01-15 09:51:16 -08:00
Jonas Devlieghere d51402ac6b [lldb] Remove reproducer instrumentation
This patch removes most of the reproducer instrumentation. It keeps
around the LLDB_RECORD_* macros for logging. See [1] for more details.

[1] https://lists.llvm.org/pipermail/lldb-dev/2021-September/017045.html

Differential revision: https://reviews.llvm.org/D116847
2022-01-09 21:40:55 -08:00
PoYao Chang 633b002944 [lldb] Fix PR52702 by fixing bool conversion of Mangled
Remove the Mangled::operator! and Mangled::operator void* where the
comments in header and implementation files disagree and replace them
with operator bool.

This fix PR52702 as https://reviews.llvm.org/D106837 used the buggy
Mangled::operator! in Symbol::SynthesizeNameIfNeeded. For example,
consider the symbol "puts" in a hello world C program:

// Inside Symbol::SynthesizeNameIfNeeded
(lldb) p m_mangled
(lldb_private::Mangled) $0 = (m_mangled = None, m_demangled = "puts")
(lldb) p !m_mangled
(bool) $1 = true          # should be false!!
This leads to Symbol::SynthesizeNameIfNeeded overwriting m_demangled
part of Mangled (in this case "puts").

In conclusion, this patch turns
callq  0x401030                  ; symbol stub for: ___lldb_unnamed_symbol36
back into
callq  0x401030                  ; symbol stub for: puts .

Differential Revision: https://reviews.llvm.org/D116217
2021-12-29 17:17:52 +08:00
Greg Clayton a2154b1951 Cache the manual DWARF index out to the LLDB cache directory when the LLDB index cache is enabled.
This patch add the ability to cache the manual DWARF indexing results to disk for faster subsequent debug sessions. Manual DWARF indexing is time consuming and causes all DWARF to be fully parsed and indexed each time you debug a binary that doesn't have an acceptable accelerator table. Acceptable accelerator tables include .debug_names in DWARF5 or Apple accelerator tables.

This patch breaks up testing by testing all of the encoding and decoding of required C++ objects in a gtest unit test, and then has a test to verify the debug info cache is generated correctly.

This patch also adds the ability to track when a symbol table or DWARF index is loaded or saved to the cache in the "statistics dump" command. This is essential to know in statistics as it can help explain why a debug session was slower or faster than expected.

Reviewed By: labath, wallace

Differential Revision: https://reviews.llvm.org/D115951
2021-12-28 11:00:28 -08:00
Pavel Labath 7406d236d8 [lldb/python] Fix (some) dangling pointers in our glue code
This starts to fix the other half of the lifetime problems in this code
-- dangling references. SB objects created on the stack will go away
when the function returns, which is a problem if the python code they
were meant for stashes a reference to them somewhere.  Most of the time
this goes by unnoticed, as the code rarely has a reason to store these,
but in case it does, we shouldn't respond by crashing.

This patch fixes the management for a couple of SB objects (Debugger,
Frame, Thread). The SB objects are now created on the heap, and
their ownership is immediately passed on to SWIG, which will ensure they
are destroyed when the last python reference goes away. I will handle
the other objects in separate patches.

I include one test which demonstrates the lifetime issue for SBDebugger.
Strictly speaking, one should create a test case for each of these
objects and each of the contexts they are being used. That would require
figuring out how to persist (and later access) each of these objects.
Some of those may involve a lot of hoop-jumping (we can run python code
from within a frame-format string). I don't think that is
necessary/worth it since the new wrapper functions make it very hard to
get this wrong.

Differential Revision: https://reviews.llvm.org/D115925
2021-12-20 09:42:08 +01:00
Jonas Devlieghere fa1260697e [lldb] Remove reproducer replay functionality
This is part of a bigger rework of the reproducer feature. See [1] for
more details.

[1] https://lists.llvm.org/pipermail/lldb-dev/2021-September/017045.html
2021-12-17 17:14:52 -08:00
Greg Clayton da816ca0cb Added the ability to cache the finalized symbol tables subsequent debug sessions to start faster.
This is an updated version of the https://reviews.llvm.org/D113789 patch with the following changes:
- We no longer modify modification times of the cache files
- Use LLVM caching and cache pruning instead of making a new cache mechanism (See DataFileCache.h/.cpp)
- Add signature to start of each file since we are not using modification times so we can tell when caches are stale and remove and re-create the cache file as files are changed
- Add settings to control the cache size, disk percentage and expiration in days to keep cache size under control

This patch enables symbol tables to be cached in the LLDB index cache directory. All cache files are in a single directory and the files use unique names to ensure that files from the same path will re-use the same file as files get modified. This means as files change, their cache files will be deleted and updated. The modification time of each of the cache files is not modified so that access based pruning of the cache can be implemented.

The symbol table cache files start with a signature that uniquely identifies a file on disk and contains one or more of the following items:
- object file UUID if available
- object file mod time if available
- object name for BSD archive .o files that are in .a files if available

If none of these signature items are available, then the file will not be cached. This keeps temporary object files from expressions from being cached.

When the cache files are loaded on subsequent debug sessions, the signature is compare and if the file has been modified (uuid changes, mod time changes, or object file mod time changes) then the cache file is deleted and re-created.

Module caching must be enabled by the user before this can be used:

symbols.enable-lldb-index-cache (boolean) = false

(lldb) settings set symbols.enable-lldb-index-cache true

There is also a setting that allows the user to specify a module cache directory that defaults to a directory that defaults to being next to the symbols.clang-modules-cache-path directory in a temp directory:

(lldb) settings show symbols.lldb-index-cache-path
/var/folders/9p/472sr0c55l9b20x2zg36b91h0000gn/C/lldb/IndexCache

If this setting is enabled, the finalized symbol tables will be serialized and saved to disc so they can be quickly loaded next time you debug.

Each module can cache one or more files in the index cache directory. The cache file names must be unique to a file on disk and its architecture and object name for .o files in BSD archives. This allows universal mach-o files to support caching multuple architectures in the same module cache directory. Making the file based on the this info allows this cache file to be deleted and replaced when the file gets updated on disk. This keeps the cache from growing over time during the compile/edit/debug cycle and prevents out of space issues.

If the cache is enabled, the symbol table will be loaded from the cache the next time you debug if the module has not changed.

The cache also has settings to control the size of the cache on disk. Each time LLDB starts up with the index cache enable, the cache will be pruned to ensure it stays within the user defined settings:

(lldb) settings set symbols.lldb-index-cache-expiration-days <days>

A value of zero will disable cache files from expiring when the cache is pruned. The default value is 7 currently.

(lldb) settings set symbols.lldb-index-cache-max-byte-size <size>

A value of zero will disable pruning based on a total byte size. The default value is zero currently.
(lldb) settings set symbols.lldb-index-cache-max-percent <percentage-of-disk-space>

A value of 100 will allow the disc to be filled to the max, a value of zero will disable percentage pruning. The default value is zero.

Reviewed By: labath, wallace

Differential Revision: https://reviews.llvm.org/D115324
2021-12-16 09:59:55 -08:00
Pavel Labath 82de8df26f [lldb] Clarify StructuredDataImpl ownership
StructuredDataImpl ownership semantics is unclear at best. Various
structures were holding a non-owning pointer to it, with a comment that
the object is owned somewhere else. From what I was able to gather that
"somewhere else" was the SBStructuredData object, but I am not sure that
all created object eventually made its way there. (It wouldn't matter
even if they did, as we are leaking most of our SBStructuredData
objects.)

Since StructuredDataImpl is just a collection of two (shared) pointers,
there's really no point in elaborate lifetime management, so this patch
replaces all StructuredDataImpl pointers with actual objects or
unique_ptrs to it. This makes it much easier to resolve SBStructuredData
leaks in a follow-up patch.

Differential Revision: https://reviews.llvm.org/D114791
2021-12-13 21:04:51 +01:00
Jan Svoboda e04fc2d88e [llvm][lldb] Remove unused SmallVectorMemoryBuffer.h includes 2021-12-09 11:32:13 +01:00
Greg Clayton 220854a47b Fix buildbots after https://reviews.llvm.org/D115073. 2021-12-07 12:19:00 -08:00
Greg Clayton cfe5d768be Fix buildbot after https://reviews.llvm.org/D115073. 2021-12-07 12:03:45 -08:00
Greg Clayton 244258e35a Modify DataEncoder to be able to encode data in an object owned buffer.
DataEncoder was previously made to modify data within an existing buffer. As the code progressed, new clients started using DataEncoder to create binary data. In these cases the use of this class was possibly, but only if you knew exactly how large your buffer would be ahead of time. This patchs adds the ability for DataEncoder to own a buffer that can be dynamically resized as data is appended to the buffer.

Change in this patch:
- Allow a DataEncoder object to be created that owns a DataBufferHeap object that can dynamically grow as data is appended
- Add new methods that start with "Append" to append data to the buffer and grow it as needed
- Adds full testing of the API to assure modifications don't regress any functionality
- Has two constructors: one that uses caller owned data and one that creates an object with object owned data
- "Append" methods only work if the object owns it own data
- Removes the ability to specify a shared memory buffer as no one was using this functionality. This allows us to switch to a case where the object owns its own data in a DataBufferHeap that can be resized as data is added

"Put" methods work on both caller and object owned data.
"Append" methods work on only object owned data where we can grow the buffer. These methods will return false if called on a DataEncoder object that has caller owned data.

The main reason for these modifications is to be able to use the DateEncoder objects instead of llvm::gsym::FileWriter in https://reviews.llvm.org/D113789. This patch wants to add the ability to create symbol table caching to LLDB and the code needs to build binary caches and save them to disk.

Reviewed By: labath

Differential Revision: https://reviews.llvm.org/D115073
2021-12-07 09:44:57 -08:00
Jaroslav Sevcik f72ae5cba1 [lldb] Fix windows path guessing for root paths
Fix recognizing "<letter>:\" as a windows path.

Differential Revision: https://reviews.llvm.org/D115104
2021-12-07 11:16:04 +01:00
Pavel Labath a52af6d371 [lldb] Remove extern "C" from lldb-swig-lua interface
This is the lua equivalent of 9a14adeae0.
2021-12-06 14:57:44 +01:00
Pavel Labath 9a14adeae0 [lldb] Remove 'extern "C"' from the lldb-swig-python interface
The LLDBSWIGPython functions had (at least) two problems:
- There wasn't a single source of truth (a header file) for the
  prototypes of these functions. This meant that subtle differences
  in copies of function declarations could go by undetected. And
  not-so-subtle differences would result in strange runtime failures.
- All of the declarations had to have an extern "C" interface, because
  the function definitions were being placed inside and extert "C" block
  generated by swig.

This patch fixes both problems by moving the function definitions to the
%header block of the swig files. This block is not surrounded by extern
"C", and seems more appropriate anyway, as swig docs say it is meant for
"user-defined support code" (whereas the previous %wrapper code was for
automatically-generated wrappers).

It also puts the declarations into the SWIGPythonBridge header file
(which seems to have been created for this purpose), and ensures it is
included by all code wishing to define or use these functions. This
means that any differences in the declaration become a compiler error
instead of a runtime failure.

Differential Revision: https://reviews.llvm.org/D114369
2021-11-30 11:06:09 +01:00
Adrian Prantl 4f215bfa6e Update unit test API usage (NFC) 2021-11-29 13:14:35 -08:00
Pavel Kosov 1aab5e653d [LLDB] Provide target specific directories to libclang
On Linux some C++ and C include files reside in target specific directories, like /usr/include/x86_64-linux-gnu.
Patch adds them to libclang, so LLDB jitter has more chances to compile expression.

OS Laboratory. Huawei Russian Research Institute. Saint-Petersburg

Reviewed By: teemperor

Differential Revision: https://reviews.llvm.org/D110827
2021-11-25 21:27:02 +03:00
Pavel Labath 165545c7a4 [lldb/gdb-remote] Ignore spurious ACK packets
Although I cannot find any mention of this in the specification, both
gdb and lldb agree on sending an initial + packet after establishing the
connection.

OTOH, gdbserver and lldb-server behavior is subtly different. While
lldb-server *expects* the initial ack, and drops the connection if it is
not received, gdbserver will just ignore a spurious ack at _any_ point
in the connection.

This patch changes lldb's behavior to match that of gdb. An ACK packet
is ignored at any point in the connection (except when expecting an ACK
packet, of course). This is inline with the "be strict in what you
generate, and lenient in what you accept" philosophy, and also enables
us to remove some special cases from the server code. I've extended the
same handling to NAK (-) packets, mainly because I don't see a reason to
treat them differently here.

(The background here is that we had a stub which was sending spurious
+ packets. This bug has since been fixed, but I think this change makes
sense nonetheless.)

Differential Revision: https://reviews.llvm.org/D114520
2021-11-25 12:34:08 +01:00
Pavel Labath 96beb30fbb [lldb] Move GetSupportedArchitectureAtIndex to PlatformDarwin
All other platforms use GetSupportedArchitectures now.
2021-11-24 15:48:23 +01:00
Pavel Labath 7f09ab08de [lldb] Fix [some] leaks in python bindings
Using an lldb_private object in the bindings involves three steps
- wrapping the object in it's lldb::SB variant
- using swig to convert/wrap that to a PyObject
- wrapping *that* in a lldb_private::python::PythonObject

Our SBTypeToSWIGWrapper was only handling the middle part. This doesn't
just result in increased boilerplate in the callers, but is also a
functionality problem, as it's very hard to get the lifetime of of all
of these objects right. Most of the callers are creating the SB object
(step 1) on the stack, which means that we end up with dangling python
objects after the function terminates. Most of the time this isn't a
problem, because the python code does not need to persist the objects.
However, there are legitimate cases where they can do it (and even if
the use case is not completely legitimate, crashing is not the best
response to that).

For this reason, some of our code creates the SB object on the heap, but
it has another problem -- it never gets cleaned up.

This patch begins to add a new function (ToSWIGWrapper), which does all
of the three steps, while properly taking care of ownership. In the
first step, I have converted most of the leaky code (except for
SBStructuredData, which needs a bit more work).

Differential Revision: https://reviews.llvm.org/D114259
2021-11-22 15:14:52 +01:00
Pavel Labath 098c01c132 [lldb] Refactor Platform::ResolveExecutable
Module resolution is probably the most complex piece of lldb [citation
needed], with numerous levels of abstraction, each one implementing
various retry and fallback strategies.

It is also a very repetitive, with only small differences between
"host", "remote-and-connected" and "remote-but-not-(yet)-connected"
scenarios.

The goal of this patch (first in series) is to reduce the number of
abstractions, and deduplicate the code.

One of the reasons for this complexity is the tension between the desire
to offload the process of module resolution to the remote platform
instance (that's how most other platform methods work), and the desire
to keep it local to the outer platform class (its easier to subclass the
outer class, and it generally makes more sense).

This patch resolves that conflict in favour of doing everything in the
outer class. The gdb-remote (our only remote platform) implementation of
ResolveExecutable was not doing anything gdb-specific, and was rather
similar to the other implementations of that method (any divergence is
most likely the result of fixes not being applied everywhere rather than
intentional).

It does this by excising the remote platform out of the resolution
codepath. The gdb-remote implementation of ResolveExecutable is moved to
Platform::ResolveRemoteExecutable, and the (only) call site is
redirected to that. On its own, this does not achieve (much), but it
creates new opportunities for layer peeling and code sharing, since all
of the code now lives closer together.

Differential Revision: https://reviews.llvm.org/D113487
2021-11-16 12:52:51 +01:00
Quinn Pham 52a3ed5b93 [lldb][NFC] Inclusive language: replace master/slave names for ptys
[NFC] This patch replaces master and slave with primary and secondary
respectively when referring to pseudoterminals/file descriptors.

Reviewed By: clayborg, teemperor

Differential Revision: https://reviews.llvm.org/D113687
2021-11-12 10:54:18 -06:00
Luís Ferreira 96a7359908 [lldb] Add support for demangling D symbols
This is part of https://github.com/dlang/projects/issues/81 .

This patch enables support for D programming language demangler by using a
pretty printed stacktrace with demangled D symbols, when present.

Signed-off-by: Luís Ferreira <contact@lsferreira.net>

Reviewed By: JDevlieghere, teemperor

Differential Revision: https://reviews.llvm.org/D110578
2021-11-11 11:11:21 +01:00
Zequan Wu cc9ced0ed4 [LLDB][Breakpad] Make lldb understand INLINE and INLINE_ORIGIN records in breakpad.
Teach LLDB to understand INLINE and INLINE_ORIGIN records in breakpad.
They have the following formats:
```
INLINE inline_nest_level call_site_line call_site_file_num origin_num [address size]+
INLINE_ORIGIN origin_num name
```
`INLNIE_ORIGIN` is simply a string pool for INLINE so that we won't have
duplicated names for inlined functions and can show up anywhere in the symbol
file.
`INLINE` follows immediately after `FUNC` represents the ranges of momery
address that has functions inlined inside the function.

Differential Revision: https://reviews.llvm.org/D113330
2021-11-10 11:20:32 -08:00
Med Ismail Bennani 738621d047 [lldb/bindings] Change ScriptedThread initializer parameters
This patch changes the `ScriptedThread` initializer in couple of ways:
- It replaces the `SBTarget` parameter by a `SBProcess` (pointing to the
  `ScriptedProcess` that "owns" the `ScriptedThread`).
- It adds a reference to the `ScriptedProcessInfo` Dictionary, to pass
  arbitrary user-input to the `ScriptedThread`.

This patch also fixes the SWIG bindings methods that call the
`ScriptedProcess` and `ScriptedThread` initializers by passing all the
arguments to the appropriate `PythonCallable` object.

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

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2021-11-10 17:43:28 +01:00
Jonas Devlieghere 05fbe75890 [lldb] Remove nested switches from ARMGetSupportedArchitectureAtIndex (NFC)
Remove the nested switches from the ARMGetSupportedArchitectureAtIndex
implementation.

Differential revision: https://reviews.llvm.org/D113155
2021-11-05 21:12:00 -07:00
Quinn Pham c71fbdd87b [NFC] Inclusive language: Remove instances of master in URLs
[NFC] This patch fixes URLs containing "master". Old URLs were either broken or
redirecting to the new URL.

Reviewed By: #libc, ldionne, mehdi_amini

Differential Revision: https://reviews.llvm.org/D113186
2021-11-05 08:48:41 -05:00
Muhammad Omair Javaid 553a872465 [LLDB] Adjust DumpDataExtractorTest.Formats for Windows
Floating point results mismtach between Visual stdio 2019 and previous
versions. This adjusts macro accordingly.
2021-11-04 08:48:26 +05:00
Raphael Isemann 58dd658583 [lldb] Fix a use-after-free in FindFileTest.cpp
ArrayRef doesn't take ownership.
2021-11-02 12:39:26 +01:00
Xu Jun dfd499a61c [lldb][NFC] avoid unnecessary roundtrips between different string types
The amount of roundtrips between StringRefs, ConstStrings and std::strings is
getting a bit out of hand, this patch avoid the unnecessary roundtrips.

Reviewed By: wallace, aprantl

Differential Revision: https://reviews.llvm.org/D112863
2021-11-01 22:15:01 -07:00
Xu Jun fe19ae352c normalize file path when searching the source map
The key stored in the source map is a normalized path string with host's
path style, so it is also necessary to normalize the file path during
searching the map

Reviewed By: wallace, aprantl

Differential Revision: https://reviews.llvm.org/D112439
2021-11-01 22:13:55 -07:00
Pavel Labath 3abd063fc7 [lldb] Make TypeSystemClang::GetFullyUnqualifiedType work for constant arrays
Unqualify (constant) arrays recursively, just like we do for pointers.
This allows for better pretty printer matching.

Differential Revision: https://reviews.llvm.org/D112708
2021-10-29 11:13:59 +02:00
Michał Górny 073c5d0e47 [lldb] [Host/Socket] Make DecodeHostAndPort() return a dedicated struct
Differential Revision: https://reviews.llvm.org/D112629
2021-10-28 09:57:50 +02:00
Pavel Labath 49481b5380 Remove ConstString from Language, LanguageRuntime, SystemRuntime and SymbolFile plugin names 2021-10-27 08:25:44 +02:00
Michał Górny 801cf36a23 [lldb] [unittests] Fix TcpListen() call in RNBSocketTest 2021-10-26 21:08:03 +02:00
Michał Górny 4373f3595f [lldb] [Host] Move port predicate-related logic to gdb-remote
Remove the port predicate from Socket and ConnectionFileDescriptor,
and move it to gdb-remote.  It is specifically relevant to the threading
used inside gdb-remote and with the new port callback API, we can
reliably move it there.  While at it, switch from the custom Predicate
to std::promise/std::future.

Differential Revision: https://reviews.llvm.org/D112357
2021-10-26 13:53:08 +02:00
Michał Górny 58d28b931f [lldb] [lldb-gdbserver] Unify listen/connect code to use ConnectionFileDescriptor
Unify the listen and connect code inside lldb-server to use
ConnectionFileDescriptor uniformly rather than a mix of it and Acceptor.
This involves:

- adding a function to map legacy values of host:port parameter
  (including legacy server URLs) into CFD-style URLs

- adding a callback to return "local socket id" (i.e. UNIX socket path
  or TCP port number) between listen() and accept() calls in CFD

- adding a "unix-abstract-accept" scheme to CFD

As an additional advantage, this permits lldb-server to accept any URL
known to CFD including the new serial:// scheme.  Effectively,
lldb-server can now listen on the serial port.  Tests for connecting
over a pty are added to test that.

Differential Revision: https://reviews.llvm.org/D111964
2021-10-26 13:06:19 +02:00
Michał Górny f279e50fd0 [lldb] [Communication] Add a WriteAll() method that resumes writing
Add a Communication::WriteAll() that resumes Write() if the initial call
did not write all data.  Use it in GDBRemoteCommunication when sending
packets in order to fix handling partial writes (i.e. just resume/retry
them rather than erring out).  This fixes LLDB failures when writing
large packets to a pty.

Differential Revision: https://reviews.llvm.org/D112169
2021-10-26 12:45:45 +02:00
Pavel Labath a458ef4f73 [lldb] Remove ConstString from Platform plugin names 2021-10-26 10:04:35 +02:00