When I have symlinked builddir on Fedora 31 x86_64 I get:
FAIL: test_libraries_svr4_libs_present (TestGdbRemoteLibrariesSvr4Support.TestGdbRemoteLibrariesSvr4Support)
----------------------------------------------------------------------
...
File "lldb/packages/Python/lldbsuite/test/tools/lldb-server/libraries-svr4/TestGdbRemoteLibrariesSvr4Support.py", line 106, in
libraries_svr4_libs_present
self.assertIn(self.getBuildDir() + "/" + lib, libraries_svr4_names)
AssertionError:
'/home/jkratoch/redhat/llvm-monorepo-clangassertsymlink/lldb-test-build.noindex/tools/lldb-server/libraries-svr4/TestGdbRemoteLibrariesSvr4Support.test_libraries_svr4_libs_present/libsvr4lib_a.so' not found in ['/home/jkratoch/redhat/llvm-monorepo/lldb/packages/Python/lldbsuite/test/tools/lldb-server/libraries-svr4/linux-vdso.so.1', '/quad/home/jkratoch/redhat/llvm-monorepo-clangassertsymlink/lldb-test-build.noindex/tools/lldb-server/libraries-svr4/TestGdbRemoteLibrariesSvr4Support.test_libraries_svr4_libs_present/libsvr4lib_a.so', '/quad/home/jkratoch/redhat/llvm-monorepo-clangassertsymlink/lldb-test-build.noindex/tools/lldb-server/libraries-svr4/TestGdbRemoteLibrariesSvr4Support.test_libraries_svr4_libs_present/libsvr4lib_b".so', '/usr/lib64/libdl-2.30.so', '/usr/lib64/libstdc++.so.6.0.27', '/usr/lib64/libm-2.30.so', '/usr/lib64/libgcc_s-9-20190827.so.1', '/usr/lib64/libc-2.30.so', '/usr/lib64/ld-2.30.so']
Config=x86_64-/quad/home/jkratoch/redhat/llvm-monorepo-clangassertsymlink/bin/clang-11
----------------------------------------------------------------------
Differential Revision: https://reviews.llvm.org/D74295
Reid found a bug in removing Listeners from a BroadcasterManager:
https://reviews.llvm.org/D74010
The bug didn't affect the case where there was only one Listener
signed up for a BroadcasterManager, which was all the extant test
case tests. The driver also only uses one listener (the debugger)
for everything, so neither the test nor anything you do with lldb
command line would have triggered the bug.
This adds a couple more tests using more listeners, and adding and
removing them in a different way, which triggers a separate code path.
Summary:
This creates a separate LLDB_TEST_SRC var to match the existing LLDB_TEST var. LLDB_TEST points to the test framework, LLDB_TEST_SRC points to the tests themselves.
The var points to the same place, but a future patch will move the tree + update var.
Reviewers: labath, JDevlieghere
Reviewed By: labath
Subscribers: merge_guards_bot, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71150
By clearing the recognizers before starting the test, we ensure that the
recognizers that get initialized when lldb starts won't alter the
expected results of this test (i.e. recognizer index).
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Summary:
To my knowledge we don't actually use or need these rules. And if we need them then
there is probably a better way to implement this than having all these random regexes.
Reviewers: labath, JDevlieghere
Reviewed By: labath, JDevlieghere
Subscribers: jingham, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74126
When a thread stops, this checks depending on the platform if the top frame is
an abort stack frame. If so, it looks for an assert stack frame in the upper
frames and set it as the most relavant frame when found.
To do so, the StackFrameRecognizer class holds a "Most Relevant Frame" and a
"cooked" stop reason description. When the thread is about to stop, it checks
if the current frame is recognized, and if so, it fetches the recognized frame's
attributes and applies them.
rdar://58528686
Differential Revision: https://reviews.llvm.org/D73303
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch has a couple of outstanding issues. The test is not python3
compatible, and it also seems to fail with python2 (at least under some
circumstances) due to an overambitious assertion.
This reverts the patch as well as subsequent fixup attempts:
014ea93376,
f5f70d1c8f.
4697e701b8.
5c15e8e682.
3ec28da6d6.
Pass the correct library directory from CMake to dotest.py when linking
liblldb, instead of trying to reconstruct the path from executable path.
This fixes link failures on platforms having non-null
LLVM_LIBDIR_SUFFIX.
Differential Revision: https://reviews.llvm.org/D73767
When a thread stops, this checks depending on the platform if the top frame is
an abort stack frame. If so, it looks for an assert stack frame in the upper
frames and set it as the most relavant frame when found.
To do so, the StackFrameRecognizer class holds a "Most Relevant Frame" and a
"cooked" stop reason description. When the thread is about to stop, it checks
if the current frame is recognized, and if so, it fetches the recognized frame's
attributes and applies them.
rdar://58528686
Differential Revision: https://reviews.llvm.org/D73303
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Changing the date2 to an timezone independent value broke the test as the data formatters
uses the current time zone for the summary (so changing it to a time zone independent value
would again break the test in some time zones). We anyway just care about this for date2
which will be printed in a timezone-independent summary.
Summary:
This test creates its dates with `NSDate dateWithNaturalLanguageString` which is deprecated and uses the current time zone of the machine to
interpret the input string. This causes that the created NSDate has a different value depending on the locale of the machine
and we hardcoded the value for California's time zone (PST) but the data formatter gives out the GMT value as a string.
This just replaces the use with the timezone-independent dateWithTimeIntervalSince1970 (which we also use in the rest of the test)
to make this pass independently of the time zone of the machine running the test.
Reviewers: mib
Reviewed By: mib
Subscribers: lldb-commits, JDevlieghere
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74038
Summary:
Currently having a typedef for ObjC types is breaking member access in LLDB:
```
typedef NSString Str;
NSString *s; s.length; // OK
Str *s; s.length; // Causes: member reference base type 'Str *' (aka 'NSString *') is not a structure or union
```
This works for NSString as there the type building from `NSString` -> `NSString *` will correctly
build a ObjCObjectPointerType (which is necessary to make member access with a dot possible),
but for the typedef the `Str` -> `Str *` conversion will produce an incorrect PointerType. The reason
for this is that our check in TypeSystemClang::GetPointerType is not desugaring the base type,
which causes that `Str` is not recognised as a type to a `ObjCInterface` as the check only sees the
typedef sugar that was put around it. This causes that we fall back to constructing a PointerType
instead which does not allow member access with the dot operator.
This patch just changes the check to look at the desugared type instead.
Fixes rdar://17525603
Reviewers: shafik, mib
Reviewed By: mib
Subscribers: mib, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73952
My refactor caused some changes in error reporting that TestAddDsymCommand.py
was checking, so this restores some of the changes to preserve the old
behavior and to un-xfail the affected test.
Differential Revision: https://reviews.llvm.org/D74001
Re-landing this now that (hopefully) all the failures this caused on the
bots have been addressed.
This patch changes the behavior of the substrs argument to self.expect.
Currently, the elements of substrs are unordered and as long as the
string appears in the output, the assertion passes.
We can be more precise by requiring that the substrings be ordered in
the way they appear. My hope is that this will make it harder to
accidentally pass a check because a string appears out of order.
Differential revision: https://reviews.llvm.org/D73766
Value::GetValueByteSize() reports the size of a Value as the size of its
underlying CompilerType. However, a host buffer that backs a Value may
be smaller than GetValueByteSize().
This situation arises when the host is only able to partially evaluate a
Value, e.g. because the expression contains DW_OP_piece.
The cleanest fix I've found to this problem is Greg's suggestion, which
is to resize the Value if (after evaluating an expression) it's found to
be too small. I've tried several alternatives which all (in one way or
the other) tried to teach the Value/ValueObjectChild system not to read
past the end of a host buffer, but this was flaky and impractical as it
isn't easy to figure out the host buffer's size (Value::GetScalar() can
point to somewhere /inside/ a host buffer, but you need to walk up the
ValueObject hierarchy to try and find its size).
This fixes an ASan error in lldb seen when debugging a clang binary.
I've added a regression test in test/functionalities/optimized_code. The
point of that test is not specifically to check that DW_OP_piece is
handled a particular way, but rather to check that lldb doesn't crash on
an input that it used to crash on.
Testing: check-lldb, and running the added tests using a sanitized lldb
--
Thanks to Jim for pointing out that an earlier version of this patch,
which simply changed the definition of Value::GetValueByteSize(), would
interact poorly with the ValueObject machinery.
Thanks also to Pavel who suggested a neat way to test this change
(which, incidentally, caught another ASan issue still present in the
original version of this patch).
rdar://58665925
Differential Revision: https://reviews.llvm.org/D73148
Specializations of the Platform class print the kernel after calling the
super method. By printing the kernel at the end in the super class, we
guarantee the order is the same on different platforms.
This patch changes the behavior of the substrs argument to self.expect.
Currently, the elements of substrs are unordered and as long as the
string appears in the output, the assertion passes.
We can be more precise by requiring that the substrings be ordered in
the way they appear. My hope is that this will make it harder to
accidentally pass a check because a string appears out of order.
Differential revision: https://reviews.llvm.org/D73766
Currently the substrs parameter takes a list of strings that need to be
found but the ordering isn't checked. D73766 might change that so this
changes a several tests so that the order of the strings in the substrs
list is in the order in which they appear in the output.
Currently the substrs parameter takes a list of strings that need to be
found but the ordering isn't checked. D73766 might change that so this
changes a several tests so that the order of the strings in the substrs
list is in the order in which they appear in the output.
Currently the substrs parameter takes a list of strings that need to be
found but the ordering isn't checked. D73766 might change that so this
changes a several tests so that the order of the strings in the substrs
list is in the order in which they appear in the output.
Currently the substrs parameter takes a list of strings that need to be
found but the ordering isn't checked. D73766 might change that so this
changes a several tests so that the order of the strings in the substrs
list is in the order in which they appear in the output.
Currently the substrs parameter takes a list of strings
that need to be found but the ordering isn't checked. D73766
might change that so this changes a several tests so that
the order of the strings in the substrs list is in the order
in which they appear in the output.
Currently if 'expect' fails and a custom msg is supplied, then lldbtest
will not print the actual command output. This makes it impossible to know
why the test actually failed. This just prints the command output even
if the msg parameter was supplied.
Summary:
There was a bug on LLDB VSCode where there was the following behavior:
//Code
```
struct foo {
int bar:
};
...
foo my_foo = {10};
```
Trying to auto-complete my_foo.b with my_foo.bar resulted instead with my_foo.my_foo.bar
This diff fixes this bug and adds some tests to check correct behavior.
It also fixes the same bug using the arrow operator (->) when user manually requests completions.
TODO: Fix bug where no recommended completions are automatically shown with arrow operator
{F11249959}
{F11249958}
Reviewers: wallace
Reviewed By: wallace
Subscribers: teemperor, labath, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73506
Summary:
Currently we crash in Clang's CodeGen when we call functions with covariant return types with this assert:
```
Assertion failed: (DD && "queried property of class with no definition"), function data, file clang/include/clang/AST/DeclCXX.h, line 433.
```
when calling `clang::CXXRecordDecl::isDerivedFrom` from the `ItaniumVTableBuilder`.
Clang seems to assume that the underlying record decls of covariant return types are already completed.
This is true during a normal Clang invocation as there the type checker will complete both decls when
checking if the overloaded function is valid (i.e., the return types are covariant).
When we minimally import our AST into the expression in LLDB we don't do this type checking (which
would complete the record decls) and we end up trying to access the invalid record decls from CodeGen
which makes us trigger the assert.
This patch just completes the underlying types of ptr/ref return types of virtual function so that the
underlying records are complete and we behave as Clang expects us to do.
Fixes rdar://38048657
Reviewers: lhames, shafik
Reviewed By: shafik
Subscribers: abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73024
When a thread stops, this checks depending on the platform if the top frame is
an abort stack frame. If so, it looks for an assert stack frame in the upper
frames and set it as the most relavant frame when found.
To do so, the StackFrameRecognizer class holds a "Most Relevant Frame" and a
"cooked" stop reason description. When the thread is about to stop, it checks
if the current frame is recognized, and if so, it fetches the recognized frame's
attributes and applies them.
rdar://58528686
Differential Revision: https://reviews.llvm.org/D73303
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
We want that the *.py names for the tests have unique names but
the current ones are sometimes very simple (e.g., "TestUniquePtr.py")
and could collide with unrelated tests. This just gives all these
tests a "FromStdModule" suffix to make these collisions less likely.
BreakpointSites know they're backed by hardware based on whether the
"hardware index" is set. This does not appear the to be done for
arm/aarch64.
https://llvm.org/PR44659
Include whether or not a breakpoint is a hardware breakpoint in the
breakpoint location. This will show up in things like the breakpoint
list.
Differential revision: https://reviews.llvm.org/D73389
Recognize hardware breakpoints as breakpoints instead of just mach
exceptions. The mach exception is the same for watch and breakpoints, so
we have to try each to figure out which is which.
Differential revision: https://reviews.llvm.org/D73401
The test was printing a char[3] variable without a terminating nul. The
memory after that variable (an unnamed bitfield) was not initialized. If
the memory happened to be nonzero, the summary provider for the variable
would run off into the next field.
This is probably not the right behavior (it should stop at the end of
the array), but this is not the purpose of this test. I have filed
pr44649 for this bug, and fixed the test to not depend on this behavior.
We ran into an assert when debugging clang and performing an expression on a class derived from DeclContext. The assert was indicating we were getting the offsets wrong for RecordDeclBitfields. We were getting both the size and offset of unnamed bit-field members wrong. We could fix this case with a quick change but as I extended the test suite to include more combinations we kept finding more cases that were being handled incorrectly. A fix that handled all the new cases as well as the cases already covered required a refactor of the existing technique.
Differential Revision: https://reviews.llvm.org/D72953
calls to commonly un-overridden methods into a function that checks whether
the method is overridden anywhere and if not directly dispatches to the
NSObject implementation.
That means if you do override any of these methods, "step-in" will not step
into your code, since we hit the wrapper function, which has no debug info,
and immediately step out again.
Add code to recognize these functions as "trampolines" and a thread plan that
will get us from the function to the user code, if overridden.
<rdar://problem/54404114>
Differential Revision: https://reviews.llvm.org/D73225
Summary:
This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do
(implement the TypeSystem interface for Clang). It also gets rid of the very confusing situation that we have both a
`clang::ASTContext` and a `ClangASTContext` in clang (which sometimes causes Clang people to think I'm fiddling
with Clang's ASTContext when I'm actually just doing LLDB work).
I also have plans to potentially have multiple clang::ASTContext instances associated with one ClangASTContext so
the ASTContext naming will then become even more confusing to people.
Reviewers: #lldb, aprantl, shafik, clayborg, labath, JDevlieghere, davide, espindola, jdoerfert, xiaobai
Reviewed By: clayborg, labath, xiaobai
Subscribers: wuzish, emaste, nemanjai, mgorny, kbarton, MaskRay, arphaman, jfb, usaxena95, jingham, xiaobai, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72684
This error is caused by a combination of a couple of factors:
- the test accidentally creating a list with a single (empty) FileSpec
instead of an empty list
- lldb overzeleously converting empty strings into nullptrs
- asan overzeleously validating symlink(2) arguments (the real symlink
call would just fail with EFAULT)
I fix this by using FileSpec::GetPath instead of GetCString. This avoids
the nullptr and also avoids inserting the path into the global string
pool.
I also enhance the test case to test both empty paths and empty lists.
Summary:
The ValueObject code checks for a special `$$dereference$$` synthetic
child to allow formatter providers to implement a natural
dereferencing behavior in `frame variable` for objects like smart
pointers.
This support was broken when used directly throught the Python API and
not trhough `frame variable`. The reason is that
SBFrame.FindVariable() will return by default the synthetic variable
if it exists, while `frame variable` will not do this eagerly. The
code in `ValueObject::Dereference()` accounted for the latter but not
for the former. The fix is trivial. The test change includes
additional covergage for the already-working bahevior as it wasn't
covered by the testsuite before.
This commit also adds a short piece of documentatione explaining that
it is possible (even advisable) to provide this synthetic child
outstide of the range of the normal children.
Reviewers: jingham
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73053
Summary:
Add setting target.auto-install-main-executable that controls whether
the main executable should be automatically installed when connected to
a remote platform even if it does not have an explicit install path
specified. The default is true as the current behaviour.
Reviewers: omjavaid, JDevlieghere, srhines, labath, clayborg
Reviewed By: clayborg
Subscribers: kevin.brodsky, lldb-commits, llvm-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71761
Summary:
Add setting target.auto-install-main-executable that controls whether
the main executable should be automatically installed when connected to
a remote platform even if it does not have an explicit install path
specified. The default is true as the current behaviour.
Reviewers: omjavaid, JDevlieghere, srhines, labath, clayborg
Reviewed By: clayborg
Subscribers: kevin.brodsky, lldb-commits, llvm-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71761
The way the IO handlers are currently managed by the debugger is wrong. The
implementation lacks proper synchronization between RunIOHandlerSync and
RunIOHandlers. The latter is meant to be run by the "main thread", while the
former is meant to be run synchronously, potentially from a different thread.
Imagine a scenario where RunIOHandlerSync is called from a different thread
than RunIOHandlers. Both functions manipulate the debugger's IOHandlerStack.
Although the push and pop operations are synchronized, the logic to activate,
deactivate and run IO handlers is not.
While investigating PR44352, I noticed some weird behavior in the Editline
implementation. One of its members (m_editor_status) was modified from another
thread. This happened because the main thread, while running RunIOHandlers
ended up execution the IOHandlerEditline created by the breakpoint callback
thread. Even worse, due to the lack of synchronization within the IO handler
implementation, both threads ended up executing the same IO handler.
Most of the time, the IO handlers don't need to run synchronously. The
exception is sourcing commands from external files, like the .lldbinit file.
I've added a (recursive) mutex to prevent another thread from messing with the
IO handlers wile another thread is running one synchronously. It has to be
recursive, because we might have to source another file when encountering a
command source in the original file.
Differential revision: https://reviews.llvm.org/D72748
Summary:
CXXRecordDecls that have a move constructor but no copy constructor need to
have their implicit copy constructor marked as deleted (see C++11 [class.copy]p7, p18)
Currently we don't do that when building an AST with ClangASTContext which causes
Sema to realise that the AST is malformed and asserting when trying to create an implicit
copy constructor for us in the expression:
```
Assertion failed: ((data().DefaultedCopyConstructorIsDeleted || needsOverloadResolutionForCopyConstructor())
&& "Copy constructor should not be deleted"), function setImplicitCopyConstructorIsDeleted, file include/clang/AST/DeclCXX.h, line 828.
```
In the test case there is a class `NoCopyCstr` that should have its copy constructor marked as
deleted (as it has a move constructor). When we end up trying to tab complete in the
`IndirectlyDeletedCopyCstr` constructor, Sema realises that the `IndirectlyDeletedCopyCstr`
has no implicit copy constructor and tries to create one for us. It then realises that
`NoCopyCstr` also has no copy constructor it could find via lookup. However because we
haven't marked the FieldDecl as having a deleted copy constructor the
`needsOverloadResolutionForCopyConstructor()` returns false and the assert fails.
`needsOverloadResolutionForCopyConstructor()` would return true if during the time we
added the `NoCopyCstr` FieldDecl to `IndirectlyDeletedCopyCstr` we would have actually marked
it as having a deleted copy constructor (which would then mark the copy constructor of
`IndirectlyDeletedCopyCstr ` as needing overload resolution and Sema is happy).
This patch sets the correct mark when we complete our CXXRecordDecls (which is the time when
we know whether a copy constructor has been declared). In theory we don't have to do this if
we had a Sema around when building our debug info AST but at the moment we don't have this
so this has to do the job for now.
Reviewers: shafik
Reviewed By: shafik
Subscribers: aprantl, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72694
Summary:
This code is handling debug info paths starting with /proc/self/cwd,
which is one of the mechanisms people use to obtain "relocatable" debug
info (the idea being that one starts the debugger with an appropriate
cwd and things "just work").
Instead of resolving the symlinks inside DWARFUnit, we can do the same
thing more elegantly by hooking into the existing Module path remapping
code. Since llvm::DWARFUnit does not support any similar functionality,
doing things this way is also a step towards unifying llvm and lldb
dwarf parsers.
Reviewers: JDevlieghere, aprantl, clayborg, jdoerfert
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71770
Those old Makefiles used completely ad-hoc rules for building files,
which means they didn't obey the test harness' variants.
They were somewhat tricky to update as they use very peculiar build
flags for some files. For this reason I was careful to compare the
build commands before and after the change, which is how I found the
discrepancy fixed by the previous commit.
While some of the make syntax used here might not be easy to grasp for
newcomers (per-target variable overrides), it seems better than to
have to repliacte the Makefile.rules logic for the test variants and
platform support.
The test harness invokes the test Makefiles with an explicit 'all'
target, but it's handy to be able to recursively call Makefile.rules
without speficying a goal.
Some time ago, we rewrote some tests in terms of recursive invocations
of Makefile.rules. It turns out this had an unintended side
effect. While using $(MAKE) for a recursive invocation passes all the
variables set on the command line down, it doesn't pass the make
goals. This means that those recursive invocations would invoke the
default rule. It turns out the default rule of Makefile.rules is not
'all', but $(EXE). This means that ti would work becuase the
executable is always needed, but it also means that the created
binaries would not follow some of the other top-level build
directives, like MAKE_DSYM.
Forcing 'all' to be the default target seems easier than making sure
all the invocations are correct going forward. This patch does this
using the .DEFAULT_GOAL directive rather than hoisting the 'all' rule
to be the first one of the file. It seems like this explicit approach
will be less prone to be broken in the future. Hopefully all the make
implementations we use support it.
This test is just TestDataFormatterObjCNSData.py copied but without any changes
(and it therefore doesn't even test NSDate).
It's also failing as NSData has been changed by me in
4f244bba4f.
These tests used "clang -mllvm -accel-tables=Dwarf" as a way to
guarantee that clang will emit the debug_names table. Unfortunately,
a change it clang made that insufficient (-gpubnames is required now
too), which rendered these tests ineffective. Since lldb automatically
falls back to the manual index, the tests didn't fail and this change
went largely unnoticed.
This patch updates the tests to really use debug_names (-gdwarf-5
-gpubnames) is the combination that works now, and it adds additional
checks to ensure the section is actually emitted.
Fortunately, no regressions crept in while these tests were disabled.
The test is currently failing on some systems with ASAN enabled due to:
```
==22898==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x603000003da4 at pc 0x00010951c33d bp 0x7ffee6709e00 sp 0x7ffee67095c0
READ of size 5 at 0x603000003da4 thread T0
#0 0x10951c33c in wrap_memmove+0x16c (libclang_rt.asan_osx_dynamic.dylib:x86_64+0x1833c)
#1 0x7fff4a327f57 in CFDataReplaceBytes+0x1ba (CoreFoundation:x86_64+0x13f57)
#2 0x7fff4a415a44 in __CFDataInit+0x2db (CoreFoundation:x86_64+0x101a44)
#3 0x1094f8490 in main main.m:424
#4 0x7fff77482084 in start+0x0 (libdyld.dylib:x86_64+0x17084)
0x603000003da4 is located 0 bytes to the right of 20-byte region [0x603000003d90,0x603000003da4)
allocated by thread T0 here:
#0 0x109547c02 in wrap_calloc+0xa2 (libclang_rt.asan_osx_dynamic.dylib:x86_64+0x43c02)
#1 0x7fff763ad3ef in class_createInstance+0x52 (libobjc.A.dylib:x86_64+0x73ef)
#2 0x7fff4c6b2d73 in NSAllocateObject+0x12 (Foundation:x86_64+0x1d73)
#3 0x7fff4c6b5e5f in -[_NSPlaceholderData initWithBytes:length:copy:deallocator:]+0x40 (Foundation:x86_64+0x4e5f)
#4 0x7fff4c6d4cf1 in -[NSData(NSData) initWithBytes:length:]+0x24 (Foundation:x86_64+0x23cf1)
#5 0x1094f8245 in main main.m:404
#6 0x7fff77482084 in start+0x0 (libdyld.dylib:x86_64+0x17084)
```
The reason is that we create a string "HELLO" but get the size wrong (it's 5 bytes instead
of 4). Later on we read the buffer and pretend it is 5 bytes long, causing an OOB read
which ASAN detects.
In general this test probably needs some cleanup as it produces on macOS 10.15 around
100 compiler warnings which isn't great, but let's first get the bot green.
This reverts D53469, which changed llvm's DWARF emission to emit
DW_AT_call_return_pc as a function-local offset. Such an encoding is not
compatible with post-link block re-ordering tools and isn't standards-
compliant.
In addition to reverting back to the original DW_AT_call_return_pc
encoding, teach lldb how to fix up DW_AT_call_return_pc when the address
comes from an object file pointed-to by a debug map. While doing this I
noticed that lldb's support for tail calls that cross a DSO/object file
boundary wasn't covered, so I added tests for that. This latter case
exercises the newly added return PC fixup.
The dsymutil changes in this patch were originally included in D49887:
the associated test should be sufficient to test DW_AT_call_return_pc
encoding purely on the llvm side.
Differential Revision: https://reviews.llvm.org/D72489
Summary:
This patch adds a new function to lldbtest: `expect_expr`. This function is supposed to replace the current approach
of calling `expect`/`runCmd` with `expr`, `p` etc.
`expect_expr` allows evaluating expressions and matching their value/summary/type/error message without
having to do any string matching that might allow unintended passes (e.g., `self.expect("expr 3+4", substrs=["7"])`
can unexpectedly pass for results like `(Class7) $0 = 7`, `(int) $7 = 22`, `(int) $0 = 77` and so on).
This only uses the function in a few places to test and demonstrate it. I'll migrate the tests in follow up commits.
Reviewers: JDevlieghere, shafik, labath
Reviewed By: labath
Subscribers: christof, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70314
The primary motivation for this is to add another dimension to the
Swift LLDB test matrix, but this seems generally useful.
Differential Revision: https://reviews.llvm.org/D72662
Summary:
This change is connected with
https://reviews.llvm.org/D69843
In large codebases, we sometimes see Module::FindFunctions (when called from
ClangExpressionDeclMap::FindExternalVisibleDecls) returning huge amounts of
functions.
In current fix I trying to return only function_fullnames from ManualDWARFIndex::GetFunctions when eFunctionNameTypeFull is passed as argument.
Reviewers: labath, jarin, aprantl
Reviewed By: labath
Subscribers: shafik, clayborg, teemperor, arphaman, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70846
When trying to interpret an expression with a function call, if the
process hasn't been launched, the expression fails to be interpreted
and the user gets the following error message:
```error: Can't run the expression locally```
This message doesn't explain why the expression failed to be
interpreted, that's why this patch improves the error message that is
displayed when trying to run an expression while no process is running.
rdar://11991708
Differential Revision: https://reviews.llvm.org/D72510
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Summary:
This renames the test `rdar-12481949` to `get-value-32bit-int` as it just tests that we return the
correct result get calling GetValueAsSigned/GetValueAsUnsigned on 32-bit integers.
It also deletes all the strange things going on in this test including resetting the data formatters (which are to my
knowledge not used to calculate scalar values) and testing Python's long integers (let's just assume that our Python
distribution works correctly). Also modernises the setup code.
Reviewers: labath, aprantl
Reviewed By: aprantl
Subscribers: JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72593
Summary:
`SBThread.GetStopDescription` is a curious API as it takes a buffer length as a parameter that specifies
how many bytes the buffer we pass has. Then we fill the buffer until the specified length (or the length
of the stop description string) and return the string length. If the buffer is a nullptr however, we instead
return how many bytes we would have written to the buffer so that the user can allocate a buffer with
the right size and pass that size to a subsequent `SBThread.GetStopDescription` call.
Funnily enough, it is not possible to pass a nullptr via the Python SWIG bindings, so that might be the
first API in LLDB that is not only hard to use correctly but impossible to use correctly. The only way to
call this function via Python is to throw in a large size limit that is hopefully large enough to contain the
stop description (otherwise we only get the truncated stop description).
Currently passing a size limit that is smaller than the returned stop description doesn't cause the
Python bindings to return the stop description but instead the truncated stop description + uninitialized characters
at the end of the string. The reason for this is that we return the result of `snprintf` from the method
which returns the amount of bytes that *would* have been written (which is larger than the buffer).
This causes our Python bindings to return a string that is as large as full stop description but the
buffer that has been filled is only as large as the passed in buffer size.
This patch fixes this issue by just recalculating the string length in our buffer instead of relying on the wrong
return value. We also have to do this in a new type map as the old type map is also used for all methods
with the given argument pair `char *dst, size_t dst_len` (e.g. SBProcess.GetSTDOUT`). These methods have
different semantics for these arguments and don't null-terminate the returned buffer (they instead return the
size in bytes) so we can't change the existing typemap without breaking them.
Reviewers: labath, jingham
Reviewed By: labath
Subscribers: clayborg, shafik, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72086
Summary:
This just adds `NO_DEBUG_INFO_TESTCASE` to tests that don't really exercise anything debug information specific
and therefore don't need to be rerun for all debug information variants.
Reviewers: labath, jingham, aprantl, mib, jfb
Reviewed By: aprantl
Subscribers: dexonsmith, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72447
This allows an unsanitized test process which loads a sanitized DSO (the
motivating example is a Swift runtime dylib) to launch on Darwin.
rdar://57290132
Differential Revision: https://reviews.llvm.org/D71379
There already are decorators and "--excluded" option to mark test-cases/files
as expected to fail. However, when a new test file is added and it which relates
to a feature that a target doesn't support, this requires either adding decorators
to that file or modifying the file provided as "--excluded" option value.
The purpose of this patch is to avoid any modifications in such cases.
E.g. if a target doesn't support "watchpoints" and passes "--xfail-category watchpoint"
to dotest, a testing job will not fail after a new watchpoint-related test file is added.
Differential Revision: https://reviews.llvm.org/D71906
This is needed to not re-write parent's categories by categories of a nested folder,
e.g. commands/expression/completion specify "cmdline" category, however it still belongs
to parent's "expression" category.
The sentinel ".categories" in the test-suite root directory is no longer needed.
Differential Revision: https://reviews.llvm.org/D71905
Summary:
Motivation: When formatting an array of typedefed chars, we would like to display the array as a string.
The string formatter currently does not trigger because the formatter lookup does not resolve typedefs for array elements (this behavior is inconsistent with pointers, for those we do look through pointee typedefs). This patch tries to make the array formatter lookup somewhat consistent with the pointer formatter lookup.
Reviewers: teemperor, clayborg
Reviewed By: teemperor, clayborg
Subscribers: clayborg, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72133
qemu has a very small maximum packet size (4096) and it actually
only uses half of that buffer for some implementation reason,
so when lldb asks for the register target definitions, the x86_64
definition is larger than 4096/2 and we need to fetch it in two parts.
This patch and test is fixing a bug in
GDBRemoteCommunicationClient::ReadExtFeature when reading a target
file in multiple parts. lldb was assuming that it would always
get back the maximum packet size response (4096) instead of
using the actual size received and asking for the next group of
bytes.
We now have two tests in gdb_remote_client for unique features
of qemu - TestNestedRegDefinitions.py would test the ability
of lldb to follow multiple levels of xml includes; I opted to
create a separate TestRegDefinitionInParts.py test to test this
wrinkle in qemu's gdb remote serial protocol stub implementation.
Instead of combining both tests into a single test file.
<rdar://problem/49537922>
Jan Kratochvil