| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
Re-ran lldb-inst on the API folder to insert missing LLDB_RECORD_DUMMY
macros.
llvm-svn: 355711
|
|
|
|
|
|
|
| |
Extend lldb-instr to insert LLDB_RECORD_DUMMY macros for currently
unsupported signatures (void and function pointers).
llvm-svn: 355710
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a macro that doesn't actually record anything but still toggles the
API boundary. Removing just the register macros for lldb::thread_t
wasn't sufficient on NetBSD because the serialization logic needed the
underlying type to be complete.
This macro should be used by functions that are currently unsupported,
as they might trip the API boundary logic. This should be easy using the
lldb-instr tool.
llvm-svn: 355709
|
|
|
|
|
|
|
|
| |
I changed the variable to an unsigned to get rid of a signed and
unsigned compare without realizing the value could be negative. This
fixes the assert instead.
llvm-svn: 355708
|
|
|
|
|
|
|
|
|
| |
The last round of logging taught us that when the test fails, lldb
is indeed aware of the thread it's failing to associate to a given
queue. Add more logging to try to figure out why the thread and the
queue do not appear related to the Queue APIs.
llvm-svn: 355706
|
|
|
|
|
|
|
| |
Otherwise including this header from more than one place will break
linking.
llvm-svn: 355684
|
|
|
|
|
|
| |
get_llvm_bin_dirs().
llvm-svn: 355661
|
|
|
|
|
|
| |
And run the actual binary so we load the shared libraries.
llvm-svn: 355658
|
|
|
|
|
|
|
|
|
| |
The overload and/or template specialization are regular functions and
should be marked inline when implemented in the header. Writing the
previous commit message should've made that obvious but I was already
overthinking it. This will fix the windows bot.
llvm-svn: 355657
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously if an invalid program was specified, there was a bug
which, when we attempted to launch the program, would report that
the operation succeeded, causing LLDB to then hang while waiting
indefinitely to receive some events from the process.
After this patch, when an invalid program is specified, we immediately
return to vs code with an error message that indicates that the
program can not be found.
Differential Revision: https://reviews.llvm.org/D59114
llvm-svn: 355656
|
|
|
|
|
|
|
| |
Not sure if this is what's causing MSVC to claim the function to be
already defined elsewhere, but worth a shot.
llvm-svn: 355654
|
|
|
|
| |
llvm-svn: 355651
|
|
|
|
| |
llvm-svn: 355650
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current record macros already log the function being called. This
patch extends the macros to also log their input arguments and removes
explicit logging from the SB API.
This might degrade the amount of information in some cases (because of
smarter casts or efforts to log return values). However I think this is
outweighed by the increased coverage and consistency. Furthermore, using
the reproducer infrastructure, diagnosing bugs in the API layer should
become much easier compared to relying on log messages.
Differential revision: https://reviews.llvm.org/D59101
llvm-svn: 355649
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
In an attempt to understand why the test is still failing after r355555,
add some logging.
llvm-svn: 355647
|
|
|
|
|
|
|
| |
It looks like the simctl tool shipped in Xcode10.2 changed the format of
its json output.
llvm-svn: 355644
|
|
|
|
|
|
|
| |
Turns out this is actually testing that editline doesn't
screw up the terminal.
llvm-svn: 355640
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Windows can't use standard i/o system calls such as read and write
to work with sockets, it instead needs to use the specific send
and recv calls. This complicates matters for the debug adapter,
since it needs to be able to work in both server mode where it
communicates over a socket, as well as non-server mode where it
communicates via stdin and stdout. To abstract this out, I've
introduced a class IOStream which hides all these details and
exposes a read/write interface that does the right on each
platform.
Differential Revision: https://reviews.llvm.org/D59104
llvm-svn: 355637
|
|
|
|
|
|
|
|
|
|
| |
debugging
This change has no effect on Release (NoAsserts) builds.
Differential Revision: https://reviews.llvm.org/D59102
llvm-svn: 355632
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 355615
|
|
|
|
|
|
|
| |
Tests that check the output of `memory find` may trip over
unreadable characters, and in Python 3 this is an error.
llvm-svn: 355612
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After D55626 I see a failure in my Fedora buildbot.
There is uninitialized variable as the Foo constructor has not been run and foo
is an autovariable.
(lldb) breakpoint set -f foo.cpp -l 11
Breakpoint 1: where = TestDataFormatter.test.tmp.out`main + 30 at foo.cpp:11:7, address = 0x000000000040112e
(lldb) run
Process 801065 stopped
* thread #1, name = 'TestDataFormatt', stop reason = breakpoint 1.1
frame #0: 0x000000000040112e TestDataFormatter.test.tmp.out`main(argc=1, argv=0x00007fffffffcc48) at foo.cpp:11:7
8 };
9
10 int main(int argc, char **argv) {
-> 11 Foo foo(1, 2.22);
12 return 0;
13 }
Process 801065 launched: '.../tools/lldb/lit/Reproducer/Functionalities/Output/TestDataFormatter.test.tmp.out' (x86_64)
(lldb) frame var
(int) argc = 1
(char **) argv = 0x00007fffffffcc48
(Foo) foo = (m_i = 4198432, m_d = 0)
While the testcase expects m_i will be 0.
Differential Revision: https://reviews.llvm.org/D59088
llvm-svn: 355611
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
lldb/cmake/modules/LLDBConfig.cmake does not build lldb-server on Windows:
if (CMAKE_SYSTEM_NAME MATCHES "Android|Darwin|FreeBSD|Linux|NetBSD")
set(LLDB_CAN_USE_LLDB_SERVER 1)
Also do not append 'platform' parameter twice - although that was quietly
ignored.
llvm-svn: 355579
|
|
|
|
|
|
|
|
|
|
|
|
| |
"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
|
|
|
|
| |
llvm-svn: 355573
|
|
|
|
| |
llvm-svn: 355572
|
|
|
|
|
|
|
| |
Recent versions of llvm monorepo builds build libc++abi.dylib as libc++abi.1.dylib.
This accespts both variants.
llvm-svn: 355571
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds test that check that functionality in lldb continues to
work when replaying a reproducer.
- Entries in image list are identical.
- That stepping behaves the same.
- That the data formatters behave the same.
Differential revision: https://reviews.llvm.org/D55626
llvm-svn: 355570
|
|
|
|
| |
llvm-svn: 355569
|
|
|
|
| |
llvm-svn: 355568
|
|
|
|
| |
llvm-svn: 355566
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 355562
|
|
|
|
| |
llvm-svn: 355561
|
|
|
|
|
|
|
|
|
|
| |
clang plugin.
NFC
Differential Revision: https://reviews.llvm.org/D59040
llvm-svn: 355560
|
|
|
|
|
|
|
|
|
| |
/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
|
|
|
|
| |
llvm-svn: 355557
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In 2010 (r118866), filtering code was added to debugserver to avoid reporting threads
that were "not ready to be displayed to the user". This code inspects the thread's
state and discards threads marked 'uninterruptible'. Turns out, this state is pretty
common and not only a characterisitic of 'user-readiness'. This filtering was tracked
down as the source of the flakiness of TestQueues and TestConcurrent* with the symptom
of missing threads.
We discussed with the kernel team and there should be no need for us to filter the
restult of task_threads(). Everything that is returned from there can be examined.
So I went on and tried to remove the filtering completely. This produces other test
failures, where we were reporting more theads than expected. Always threads that had
been terminated, but weren't removed from the task bookkeeping structures yet. Those
threads always had a PC of 0.
This patch changes the heuristic to make the filtering a little less strict and only
rejects threads that are 'uninteruptible' *and* have a PC of 0. This has proven to be
solid in my testing.
Reviewers: jasonmolenda, clayborg, jingham
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D58912
llvm-svn: 355555
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In mail
[lldb-dev] Remote debugging a docker process
https://lists.llvm.org/pipermail/lldb-dev/2019-March/014795.html
user was confused by --min-gdbserver-port and --max-gdbserver-port options
being ignored. I think there is even a bug that --max-gdbserver-port is upper
exclusive limit (and not upper inclusive limit appropriate for max).
At least this patch should catch such mistake by an error message. The question
is whether --max-gdbserver-port should not be changed to really be max and not
max+1 but that would break backward compatibility.
Now the mail example does produce:
error: --min-gdbserver-port (5001) is not lower than --max-gdbserver-port (5001)
Differential Revision: https://reviews.llvm.org/D58962
llvm-svn: 355554
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 355548
|
|
|
|
| |
llvm-svn: 355536
|
|
|
|
| |
llvm-svn: 355531
|
|
|
|
|
|
|
|
| |
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
|