I committed an implementation of GetClangResourceDir on windows but
forgot to update this test. I merged the tests like I intended to, but I
realized that the test was actually failing. After looking into it, it
appears that FileSystem::Resolve was taking the path and setting
the FileSpec's Directory to "/path/to/lldb/lib/clang/" and the File to
"9.0.0" which isn't what we want. So I removed the resolve line from
DefaultComputeClangResourceDir.
llvm-svn: 355648
Summary: This function is useful for expression evaluation, especially when doing swift debugging on windows.
Reviewers: aprantl, labath
Reviewed By: labath
Subscribers: teemperor, jdoerfert, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D59072
llvm-svn: 355631
Summary: DW_OP_GNU_addr_index has been renamed as DW_OP_addrx in the standard. clang produces DW_OP_addrx tags and with this change lldb starts to process them.
Reviewers: aprantl, jingham, davide, clayborg, serge-sans-paille
Reviewed By: aprantl
Subscribers: jdoerfert, dblaikie, labath, shafik, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D59004
llvm-svn: 355629
As discussed on the mailing list, default serialization for thread ids
is not correct, even if they're represented as basic types. I'm
purposely leaving the corresponding record macros in place so that we
don't break the API boundary detection.
llvm-svn: 355610
"apple-latest" which llvm uses to indicate the newest supported ISA.
Add a unit test; I'm only testing an armv8.1 instruction in this
unit test which would already be disassembled correctly because we
set the disassembler to ARM v8.2 mode, but it ensures that nothing
has been broken by adding this cpu spec.
<rdar://problem/38714781>
llvm-svn: 355578
Summary:
If LLDB_DISABLE_PYTHON is set, some functions are unavailable but
SBReproducer assumes they are. Let's conditionally register those functions
since they are conditionally declared.
Differential Revision: https://reviews.llvm.org/D59056
llvm-svn: 355575
DynamicLoaderDarwinKernel::KextImageInfo::LoadImageUsingMemoryModule
which would list every kext that failed to load when doing kernel
debugging. Instead, in DynamicLoaderDarwinKernel::ParseKextSummaries,
print a summary of how many kexts lldb was unable to load at the end.
I want to reduce the amount of output at the start of kernel debug
sessions a bit; we'll see if anyone really wanted to see the list of
which kexts specifically were unable to be loaded.
No functional change, only changing lldb's output at the start of
a kernel debug session.
<rdar://problem/48654569>
llvm-svn: 355565
/BIGOBJ is used to bypass certain COFF file format
limitations and is used with, unsurprisingly, very big
object files. This file has grown large enough that it
needs this flag in order to compile successfully.
llvm-svn: 355559
My apologies for the large patch. With the exception of ConstString.h
itself it was entirely produced by sed.
ConstString has exactly one const char * data member, so passing a
ConstString by reference is not any more efficient than copying it by
value. In both cases a single pointer is passed. But passing it by
value makes it harder to accidentally return the address of a local
object.
(This fixes rdar://problem/48640859 for the Apple folks)
Differential Revision: https://reviews.llvm.org/D59030
llvm-svn: 355553
This was reverted because it breaks the GreenDragon bot, but
the reason for the breakage is lost, so I'm resubmitting this
now so we can find out what the problem is.
llvm-svn: 355528
Core files need to know the size of the PRSTATUS header so that we can grab the register values that follow it. The code that figure out this size was using a hard coded list of architecture cores instead of relying on 32 or 64 bit for most cores.
The fix here fixes core files for 32 bit ARM. Prior to this the PRSTATUS header size was being returned as zero and the register values were being taken from the first bytes of the PRSTATUS struct (signo, etc).
Differential Revision: https://reviews.llvm.org/D58985
llvm-svn: 355526
On Windows, lldb::thread_t is just a void*, so the we will try to
allocate an object of type void when deserializing. Undef this for now
until we support void* arguments.
llvm-svn: 355519
Summary:
This file implements some general purpose data structures, and so it
belongs to the Utility module.
Reviewers: zturner, jingham, JDevlieghere, clayborg, espindola
Subscribers: emaste, mgorny, javed.absar, arichardson, MaskRay, lldb-commits
Differential Revision: https://reviews.llvm.org/D58970
llvm-svn: 355509
Currently when lldb might be doing a kernel debug session, it scans through
memory by taking the current pc value and looking for a kernel at megabyte
boundaries, up to 32MB behind $pc. This adjusts the algorithm to
scan back at every 16k page boundary and to stop scanning as soon
as we hit a memory read error. The addition of stopping at a memory read
error saves us from tons of unnecessary packet traffic on generic
targets where lldb might look for a kernel binary.
I've been trying to think of how to construct a test for this; it's a bit
tricky. A gdb-remote protocol test with the contents of a fake tiny kernel
mach-o binary would satisify part of it, but this kernel path also directly
calls over to dsymForUUID or DebugSymbols framework lookups to find the
kernel binary as well. I'll keep thinking about this one, but it's so
intertangled with these two external systems that it may be hard to do.
<rdar://problem/48578197>
llvm-svn: 355476
The function signature of ComputeClangResourceDirectory for windows
wasn't updated when the others changed, causing the windows build to
fail. This should fix that.
llvm-svn: 355471
Now that the LLDB instrumentation macros are in place, we should use
that to test reproducer replay.
Differential revision: https://reviews.llvm.org/D58565
llvm-svn: 355470
Summary:
I'm doing this because I plan on implementing `ComputeClangResourceDirectory`
on windows so that `GetClangResourceDir` will work. Additionally, I made
test_paths make sure that the directory member of the returned FileSpec is not
none. This will fail on windows since `ComputeClangResourceDirectory` isn't
implemented yet.
Differential Revision: https://reviews.llvm.org/D58748
llvm-svn: 355463
This patch adds the SBReproducer macros needed to capture and reply the
corresponding calls. This patch was generated by running the lldb-instr
tool on the API source files.
Differential revision: https://reviews.llvm.org/D57475
llvm-svn: 355459
When running the test suite with the instrumentation macros, I noticed
two lldb-mi tests regressed. The issue was the copy constructor of
SBLineEntry. Without the macros the returned value would be elided, but
with the macros the copy constructor was called. The latter using ::IsValid
to determine whether the underlying opaque pointer should be set. This
is likely a remnant of when ::IsValid would only check the validity of the
smart pointer. In SBLineEntry however, it actually forwards to
LineEntry::IsValid().
So what happened here was that because of the macros the copy
constructor was called. The opaque pointer was valid but the LineEntry
didn't consider itself valid. So the copied-to object ended up default
initialized.
This patch replaces all checks for IsValid in copy (assignment)
constructors with checks for the opaque pointer itself.
Differential revision: https://reviews.llvm.org/D58946
llvm-svn: 355458
The intention in r355323 has been to implement a no-op resolver in the
HostInfoBase class, which will then be shadowed a an implementation in
the HostInfoPosix class. However, I add the shadowing declaration in
HostInfoPosix.h, and instead had implemented the HostInfoBase function
in HostInfoPosix.cpp. This has lead to undefined symbols on windows, and
a subsequent implementation of a no-op resolver in HostInfoWindows
(r355329).
Since now there is no point on having a no-op resolver in the base
class, I just remove the base declaration altogether, and have
HostInfoPosix implement the (newly-declared) HostInfoPosix version of
that function.
llvm-svn: 355398
There are set of classes in Target that describe the parameters of a
process - e.g. it's PID, name, user id, and similar. However, since it
is a bare description of a process and contains no actual functionality,
there's nothing specifically that makes this appropriate for being in
Target -- it could just as well be describing a process on the host, or
some hypothetical virtual process that doesn't even exist.
To cement this, I'm moving these classes to Utility. It's possible that
we can find a better place for it in the future, but as it is neither
Host specific nor Target specific, Utility seems like the most appropriate
place for the time being.
After this there is only 2 remaining references to Target from Host,
which I'll address in a followup.
Differential Revision: https://reviews.llvm.org/D58842
llvm-svn: 355342
Summary:
The current install-clang-headers target installs clang's resource
directory headers. This is different from the install-llvm-headers
target, which installs LLVM's API headers. We want to introduce the
corresponding target to clang, and the natural name for that new target
would be install-clang-headers. Rename the existing target to
install-clang-resource-headers to free up the install-clang-headers name
for the new target, following the discussion on cfe-dev [1].
I didn't find any bots on zorg referencing install-clang-headers. I'll
send out another PSA to cfe-dev to accompany this rename.
[1] http://lists.llvm.org/pipermail/cfe-dev/2019-February/061365.html
Reviewers: beanz, phosek, tstellar, rnk, dim, serge-sans-paille
Subscribers: mgorny, javed.absar, jdoerfert, #sanitizers, openmp-commits, lldb-commits, cfe-commits, llvm-commits
Tags: #clang, #sanitizers, #lldb, #openmp, #llvm
Differential Revision: https://reviews.llvm.org/D58791
llvm-svn: 355340
That patch added a function to HostInfo that returns an instance
of UserIDResolver, but this function was unimplemented on Windows,
leading to linker errors. For now, just return a dummy implementation
that doesn't resolve user ids to get the build green.
llvm-svn: 355329
Summary:
This creates an abstract base class called "UserIDResolver", which can
be implemented to provide user/group ID resolution capabilities for
various objects. Posix host implement a PosixUserIDResolver, which does
that using posix apis (getpwuid and friends). PlatformGDBRemote
forwards queries over the gdb-remote link, etc. ProcessInstanceInfo
class is refactored to make use of this interface instead of taking a
platform pointer as an argument. The base resolver class already
implements caching and thread-safety, so implementations don't have to
worry about that.
The main motivating factor for this was to remove external dependencies
from the ProcessInstanceInfo class (so it can be put next to
ProcessLaunchInfo and friends), but it has other benefits too:
- ability to test the user name caching code
- ability to test ProcessInstanceInfo dumping code
- consistent interface for user/group resolution between Platform and
Host classes.
Reviewers: zturner, clayborg, jingham
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D58167
llvm-svn: 355323
Use '127.0.0.1' instead of 'localhost' in ConnectLocally() function
as this is the specific address the server is bound to. Using
'localhost' may involve trying IPv6 first which may accidentally be used
by another service.
While technically it might be interesting to support IPv6 here, it would
need to be supported properly, with the connection copying family
and address from the listening socket, and possibly without relying
on existence of 'localhost' at all.
Differential Revision: https://reviews.llvm.org/D58883
llvm-svn: 355285
automatic move should not fire when returning type T in a function with
result type Expected<T>. Some compilers seem to allow that nonetheless.
llvm-svn: 355270
Alex Langford