There was a little bit of logic in the StopInfoBreakpoint::PerformAction
that would null out the StopInfo once we had a completed plan so that the
next call to GetStopInfo would replace it with the StopInfoThreadPlan.
But the stop-hooks check for whether a thread stopped for a reason didn't
trigger this conversion. So I added an API to do that directly, and then
called it where before we just reset the StopInfo.
<rdar://problem/54270767>
Differential Revision: https://reviews.llvm.org/D66241
llvm-svn: 369052
Summary:
Currently the heuristic used in ClangASTContext::CreateRecordType to identify an anonymous class is that there is that name is a nullptr or simply a null terminator. This heuristic is not accurate since it will also sweep up unnamed classes and lambdas. The improved heuristic relies on the requirement that an anonymous class must be contained within a class.
Differential Revision: https://reviews.llvm.org/D66175
llvm-svn: 368937
Summary:
It seems this was an unintended side-effect of D26698. AFAICT, these
functions did return an empty string before that patch, and the patch
contained code which attempted to ensure that, but those efforts were
negated by ConstString::AsCString, which by default returns a nullptr
even for empty strings.
This patch:
- fixes the GetOutput/Error methods to really return empty strings
- adds and explicit test for that
- removes a workaround in lldbtest.py, which was masking this problem
from our other tests
Reviewers: jingham, clayborg
Subscribers: zturner, lldb-commits
Differential Revision: https://reviews.llvm.org/D65739
llvm-svn: 368806
Summary: Thanks to Hui Huang and reviewers for all the help with this patch!
Reviewers: labath, jfb, clayborg
Reviewed By: labath
Subscribers: Hui, clayborg, dexonsmith, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D61687
llvm-svn: 368776
Summary: Thanks to Hui Huang and the reviewers for all the help with this patch.
Reviewers: labath, Hui, jfb, clayborg, amccarth
Reviewed By: labath
Subscribers: amccarth, compnerd, dexonsmith, mgorny, jfb, teemperor, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D63165
llvm-svn: 368759
We have no test coverage for the IOHandler code that is doing the
completion in the command line. This is adding a pexpect-based test
as a preparation for the switch to using CompletionRequest in the
whole completion machinery.
llvm-svn: 368679
Summary:
Our IR rewriting infrastructure currently fails when it encounters a variable which has no metadata associated.
This causes dynamic_cast to fail as in this case IRForTarget considers the type info pointers ('@_ZTI...') to be
variables without associated metadata. As there are no variables for these internal variables, this is actually
not an error and dynamic_cast would work fine if we didn't throw this error.
This patch fixes this by removing this diagnostics code. In case we would actually hit a variable that has no
metadata (but is supposed to have), we still have the error in the expression log so this shouldn't make it
harder to diagnose any missing metadata errors.
This patch should fix dynamic_cast and also adds a bunch of test coverage to that language feature.
Fixes rdar://10813639
Reviewers: davide, labath
Reviewed By: labath
Subscribers: friss, labath, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D65932
llvm-svn: 368511
If a bitfield doesn't fit into the child_byte_size'd window at
child_byte_offset, move the window forward until it fits. The problem
here is that Value has no notion of bitfields and thus the Value's
DataExtractor is sized like the bitfields CompilerType; a sequence of
bitfields, however, can be larger than their underlying type.
This was not in the big-endian-derived DWARF 2 bitfield attributes
because their offsets were counted from the end of the window, so they
always fit.
rdar://problem/53132189
Differential Revision: https://reviews.llvm.org/D65492
llvm-svn: 368226
Summary:
The change https://reviews.llvm.org/D55575 modified ClangASTContext::CreateParameterDeclaration to call decl_ctx->addDecl(decl); this caused a regression since the existing code in DWARFASTParserClang::ParseChildParameters is called with the containing DeclContext. So when end up with cases where we are parsing a parameter for a member function and the parameter is added to the CXXRecordDecl as opposed to the CXXMethodDecl. This example is given in the regression test TestBreakpointInMemberFuncWNonPrimitiveParams.py which without this fix in a modules build leads to assert on setting a breakpoint in a member function with non primitive parameters. This scenario would be common when debugging LLDB or clang.
Differential Revision: https://reviews.llvm.org/D65414
llvm-svn: 367726
Summary: We have been seeing increased reports of performance issue around large project and formatting std::function variables especially in functions signatures in back traces. There are some possible fixes but exploring those fixes may take time and it is better to temporarily disable the formatter due to its impact and re-enable it once we have a fix.
Differential Revision: https://reviews.llvm.org/D65666
llvm-svn: 367701
For security reasons, DYLD_INSERT_LIBRARIES is not propagated to a child
process. This breaks the skipIfSanitized decorator, which checks for the
environment variable being set. Instead, always set the ASAN_OPTIONS and
make the decorator check for that.
Differential revision: https://reviews.llvm.org/D65594
llvm-svn: 367595
This test was frequently hanging on Windows, causing a timeout after
10 minutes. The short delay (100 microsecond) in the sample program
could cause a deadlock in the Windows thread pool, as I've explained
in the test program's comments.
Now that it doesn't hang, it passes reliably, so I've removed the
Windows-specific XFAIL.
I've tried to clarify the comments in TestThreadSpecificGBreakpoint.py
by eliminating some redundancy and typos, and I simplified away a
couple unnecessary assignments.
Differential Revision: https://reviews.llvm.org/D65546
llvm-svn: 367573
I was going through some of the old bugs and came across PR21069 which I
was able to reproduce. The issue is that we match the regex `^foo`
against the `DW_AT_name` in the DWARF, which for our anonymous function
is indeed `foo`. However, when we get the function name from the symbol
context, the result is `(anonymous namespace)::foo()`. This throws off
completions, which assumes that it's appending to whatever is already
present on the input, resulting in a bogus
`b fooonymous\ namespace)::foo()`.
Bug report: https://llvm.org/PR21069
Differential revision: https://reviews.llvm.org/D65498
llvm-svn: 367455
Now that the Xcode project is removed, I want to focus on dotest as a
test framework, and remove its driver capabilities for which we already
rely on llvm's lit. Removing multiprocessing is the first step in that
direction.
Differential revision: https://reviews.llvm.org/D65311
llvm-svn: 367331
Summary:
Tab completing inside the multiline expression command can cause LLDB to crash. The easiest way
to do this is to go inside a frame with at least one local variable and then try to complete:
(lldb) expr
1. a[tab]
Reason for this was some mixup when we calculate the cursor position. Obviously we should calculate
the offset inside the string by doing 'end - start', but we are doing 'start - end' (which causes the offset to
become -1 which will lead to some out-of-bounds reading).
Fixes rdar://51754005
I don't see any way to test this as the *multiline* expression completion is completely untested at the moment
and I don't think we have any existing code for testing infrastructure for it.
Reviewers: shafik, davide, labath
Reviewed By: labath
Subscribers: abidh, lldb-commits, davide, clayborg, labath
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64995
llvm-svn: 367308
Compare the directory paths returned by lldb-vscode against realpaths
rather than apparent paths. This matches lldb-vscode behavior
and therefore fixes test failures when one of the parent directories
of the source tree is a symlink.
Differential Revision: https://reviews.llvm.org/D65432
llvm-svn: 367291
The test was not previously run due to decorator bug (fixed in r366903).
It is not a regression and is probably related to the other failing
test, so just disable it.
llvm-svn: 367285
Summary:
This doubles the 3 tests running right now on linux by also executing each test with libraries-svr4 enabled.
Not sure if there's a better way to do this as I had to copy/paste all the decorators as well...
Reviewers: labath, clayborg, xiaobai
Reviewed By: labath
Subscribers: srhines, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D65129
llvm-svn: 367247
rL357954 did increase `packet-timeout` 1sec -> 5secs. Which is IMO about the
maximum timeout reasonable for regular use. But for testsuite I think the
timeout should be higher as the testsuite runs in parallel and it can be run
even on slow hosts and with other load (moreover if it runs on some slow arch).
I have chosen 60 secs, that should be enough hopefully. Larger value could
make debugging with hanging `lldb-server` annoying.
This patch was based on this testsuite timeout:
http://lab.llvm.org:8014/builders/lldb-x86_64-fedora/builds/546/steps/test/logs/stdio
FAIL: test_connect (TestGDBRemoteClient.TestGDBRemoteClient)
Test connecting to a remote gdb server
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/jkratoch/slave-lldb-x86_64-fedora/lldb-x86_64-fedora/llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestGDBRemoteClient.py", line 13, in test_connect
process = self.connect(target)
File "/home/jkratoch/slave-lldb-x86_64-fedora/lldb-x86_64-fedora/llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/gdbclientutils.py", line 480, in connect
self.assertTrue(error.Success(), error.description)
AssertionError: False is not True : failed to get reply to handshake packet
Differential Revision: https://reviews.llvm.org/D65271
llvm-svn: 367234
We noticed that TestInferiorCrashing.py and TestRecursiveInferior.py are
the second and third slowest tests in the test suite. Splitting them up
allows lit to schedule them more effectively.
llvm-svn: 367077
Dotest contains code to clear DYLD_LIBRARY_PATH for the inferior to not
propagate sanitized builds. However, it's possible that we want to
inject a different library path with `--inferior-env`. To make that work
correctly, we need to do that *after* clearing DYLD_LIBRARY_PATH.
llvm-svn: 367054
Mark the process as stopped when SIGSTOP arrives. This is necessary
for lldb-server to generate correct response to 'process interrupt',
and therefore to prevent the whole stack crashing when process
is stopped.
Thanks to Pavel Labath for the tip.
Differential Revision: https://reviews.llvm.org/D65289
llvm-svn: 367047
Summary:
Due to a logic error, lldb-server ended up asserting/crashing every time
the debugged process attempted an execve(). This fixes the error, and
extends TestExec to work on other platforms too. The "extension"
consists of avoiding non-standard posix_spawn extensions and using the
classic execve() call, which should be available on any platform that
actually supports re-execing. I change the test decorator from
@skipUnlessDarwin to @skipIfWindows.
Reviewers: clayborg, jasonmolenda
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D65207
llvm-svn: 366985
Summary: update some test decorates that can actually pass on andriod aarch64
Patch by Wanyi Ye <kusmour@gmail.com>
Differential Revision: https://reviews.llvm.org/D64767
llvm-svn: 366858
On slower machines the vscode testcases were sometimes hanging:
1910 ? Sl 0:00 | \_ /usr/bin/python .../llvm/tools/lldb/test/dotest.py ... -p TestVSCode_setBreakpoints.py
2649 ? Sl 0:00 | \_ .../build/bin/lldb-vscode
2690 ? S 0:00 | \_ .../build/bin/lldb-server gdbserver --fd=9 --native-regs --setsid
2708 ? t 0:00 | \_ .../build/lldb-test-build.noindex/tools/lldb-vscode/breakpoint/TestVSCode_setBreakpoints.test_functionality/a.out
A reproducer of the racy bug for send_recv():
# self.send_packet(command)
#+ import time
#+ time.sleep(1)
# done = False
I guess `request_continue` was probably originally intended to be synchronous
but then it isn't and this code has been leftover there.
Differential revision: https://reviews.llvm.org/D65163
llvm-svn: 366850
Summary:
Delete the duplicate func `skipIfTargetAndroid`
Fix the old one. It didn't work for missing an argument `bugnumber`, this somehow made the decorator failed
Differential Revision: https://reviews.llvm.org/D64583
Patch by Wanyi Ye <kusmour@gmail.com>
llvm-svn: 366771
Summary:
We assume in LLDB that every type comes from an ASTContext with an associated ClangASTContext.
However the types inside the ClangModuleDeclVendor don't have a ClangASTContext so we end up
crashing whenever we create a CompilerType for one of these types.
Simplest way to trigger this bug is to just look up NSObject from a module:
(lldb) expr @import Foundation
(lldb) type lookup NSObject
Assertion failed: (m_type_system != nullptr), function CompilerType, file /Users/teemperor/llvm1/llvm-project/lldb/source/Symbol/CompilerType.cpp, line 39.
This patch just creates a ClangASTContext for the ASTContext used by ClangModuleDeclVendor.
Reviewers: davide, shafik
Reviewed By: davide
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64989
llvm-svn: 366653
Summary: lldb-mi has been removed, but there are still a bunch of references in the code base. This patch removes all of them.
Reviewers: JDevlieghere, jfb
Reviewed By: JDevlieghere
Subscribers: dexonsmith, ki.stfu, mgorny, abidh, jfb, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64992
llvm-svn: 366590
Summary:
Add __kernel_rt_sigreturn to the list of trap handlers for Linux (it's
used as such on aarch64 at least), and __restore_rt as well (used on
x86_64).
Skip decrement-and-recompute for trap handlers in
InitializeNonZerothFrame, as signal dispatch may point the child frame's
return address to the start of the return trampoline.
Parse the 'S' flag for signal handlers from eh_frame augmentation, and
propagate it to the unwind plan.
Reviewers: labath, jankratochvil, compnerd, jfb, jasonmolenda
Reviewed By: jasonmolenda
Subscribers: clayborg, MaskRay, wuzish, nemanjai, kbarton, jrtc27, atanasyan, jsji, javed.absar, kristof.beyls, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D63667
llvm-svn: 366580
When two .c files define a type of the same name, lldb
just picks one and uses it regardless of context. That is
not correct. When stopped in a frame in one of the .c files
that define this type, it should use that local definition.
This commit just adds a test that checks for the correct
behavior. It is currently xfailed.
llvm-svn: 366507
Summary:
We currently don't support offsetof in the expression evaluator as it is implemented as a macro
(which then calls __builtin_offsetof) in stddef.h. The best solution would be to include that
header (or even better, import Clang's builtin module), but header-parsing and
(cross-platform) importing modules is not ready yet.
Until we get this working with modules I would say we add the macro to our existing macro list
as we already do with other macros from stddef.h/stdint.h. We should be able to drop all of them
once we can import the relevant modules by default.
rdar://26040641
Reviewers: shafik, davide
Reviewed By: davide
Subscribers: clayborg, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64917
llvm-svn: 366476
If a core file has an EFI version string which includes a UUID
(similar to what it returns for the kdp KDP_KERNELVERSION packet)
in the LC_IDENT or LC_NOTE 'kern ver str' load command. In that
case, we should try to find the binary and dSYM for the UUID
listed. The dSYM may have python code which knows how to relocate
the binary to the correct address in lldb's target section load
list and loads other ancillary binaries.
The test case is a little involved,
1. it compiles an inferior hello world apple (a.out),
2. it compiles a program which can create a corefile manually
with a specific binary's UUID encoded in it,
3. it gets the UUID of the a.out binary,
4. it creates a shell script, dsym-for-uuid.sh, which will
return the full path to the a.out + a.out.dSYM when called
with teh correct UUID,
5. it sets the LLDB_APPLE_DSYMFORUUID_EXECUTABLE env var before
creating the lldb target, to point to this dsym-for-uuid.sh,
6. runs the create-corefile binary we compiled in step #2,
7. loads the corefile from step #6 into lldb,
8. verifies that lldb loaded a.out by reading the LC_NOTE
load command from the corefile, calling dsym-for-uuid.sh with
that UUID, got back the path to a.out and loaded it.
whew!
<rdar://problem/47562911>
llvm-svn: 366378
In ClangASTContext::CreateFunctionTemplateSpecializationInfo a TemplateArgumentList is allocated on the stack but is treated as if it is persistent in subsequent calls. When we exit the function func_decl will still point to the stack allocated memory. We will use TemplateArgumentList::CreateCopy instead which will allocate memory out of the DeclContext.
Differential Revision: https://reviews.llvm.org/D64777
llvm-svn: 366365
Disable colors so we don't risk having unexpected ANSI codes in the test
output. Currently, the behavior of a test can change depending on
whether it's run under a color-supporting terminal, or under a dummy
terminal, for example when using lit or multiprocessing.
llvm-svn: 366356
Jim Ingham