| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
I was over-eager to unable this test in r304976. It still fails in this
combination, at there does not seem to be anything we can do about it,
as the generated code does not preserve the link register.
llvm-svn: 305062
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When a call instruction is the last instruction in a function, the
backtrace PC will point past the end of the function. We already had
special code to handle that, but we did not handle the case where the PC
ends up outside of the bounds of the module containing the function,
which is a situation that occured in TestNoreturnUnwind on android for
some arch/compiler combinations.
I fix this by adding an argument to Address resolution code which states
that we are ok with addresses pointing to the end of a module/section to
resolve to that module/section.
I create a reproducible test case for this situation by hand-crafting an
executable which has a noreturn function at the end of a module.
Reviewers: jasonmolenda, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D32022
llvm-svn: 304976
|
|
|
|
|
|
| |
other test directories.
llvm-svn: 303643
|
|
|
|
|
|
| |
kernel bug
llvm-svn: 303160
|
|
|
|
|
|
|
|
|
|
| |
as described in pr33042, we cannot reliably retrieve the return value on
arm64 in cases it is returned via x8 pointer. I tried to do this as
surgically as possible and disabled it only on targets I know to be
affected, as the code is still useful, even though it can only work on
best-effort basis.
llvm-svn: 303076
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Arm64 Procedure Call Standard specifies than only vectors up to 16 bytes
are stored in v0 (which makes sense, as that's the size of the
register). 32-byte vector types are passed as regular structs via x8
pointer. Treat them as such.
This fixes TestReturnValue for arm64-clang. I also split the test case
into two so I can avoid the if(gcc) line, and annotate each test
instead. (It seems the vector type tests fail with gcc only when
targetting x86 arches).
Reviewers: tberghammer, eugene
Subscribers: aemerson, omjavaid, rengolin, srhines, lldb-commits
Differential Revision: https://reviews.llvm.org/D32813
llvm-svn: 302220
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: jingham, labath
Subscribers: jaydeep, bhushan, lldb-commits, slthakur
Differential Revision: https://reviews.llvm.org/D32168
llvm-svn: 302139
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The existing cpp-level checks using PR_MPX_ENABLE_MANAGEMENT aren't sufficient,
as this isn't defined for linux kernel versions below 3.19.
Reviewers: valentinagiusti, zturner, labath
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D32719
llvm-svn: 302027
|
|
|
|
|
| |
Subscribers: jaydeep, bhushan, lldb-commits, slthakur
llvm-svn: 301295
|
|
|
|
|
|
|
| |
- XFAIL on TestNoreturnUnwind on all architectures
- TestStaticVariables fails with clang-3.8 as well
llvm-svn: 301186
|
|
|
|
|
|
|
| |
older versions of libc++ (still used on some linux systems) are not
compatible with gcc.
llvm-svn: 300837
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
MergeFrom was updating the architecture if the target triple did not
have it set. However, it was leaving the core field as invalid. This
resulted in assertion failures in core file tests as a missing core
meant we were unable to compute the address byte size properly.
Add a unit test for the new behaviour.
Reviewers: jingham, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D32221
llvm-svn: 300836
|
|
|
|
|
|
|
|
| |
I thought my previous commit got the last ones but somehow I missed
these. This also resurrects TestDataFormatterLibcxxSet, which got
commented out in r263859 as a part of some seemingly unrelated change.
llvm-svn: 300833
|
|
|
|
|
|
| |
<rdar://problem/31713267>
llvm-svn: 300785
|
|
|
|
|
|
|
|
|
|
| |
r285226 dropped the code that did these checks. I am pretty
sure that was inadvertent, so I added that back in and added
a test for it.
<rdar://problem/31661252>
llvm-svn: 300564
|
|
|
|
| |
llvm-svn: 300054
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The iteration list through the available data formatters was undefined,
which meant that the vector<bool> formatter kicked in only in cases
where it happened to be queried before the general vector formatter. To
fix this, I merge the two data formatter entries into one, and select
which implementation to use in the factory function.
Reviewers: jasonmolenda, tberghammer, EricWF
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D31880
llvm-svn: 300047
|
|
|
|
|
|
|
|
| |
gcc emits DW_LANG_C89 even if we specify -std=c99 during compilation.
Since this isn't an lldb bug, but just the way the compiler happens to
be implemented, I teach the test to expect this situation correctly.
llvm-svn: 300046
|
|
|
|
|
|
| |
<rdar://problem/31411646>
llvm-svn: 300012
|
|
|
|
| |
llvm-svn: 299934
|
|
|
|
|
|
| |
llvm.org/pr32553 and <rdar://problem/30646077> are tracking this.
llvm-svn: 299807
|
|
|
|
|
|
|
| |
The skipping logic for the test have been fixed recently but the test is
very flakey on the buildbot.
llvm-svn: 299677
|
|
|
|
|
|
| |
This makes sure we are able to run them properly on android.
llvm-svn: 299588
|
|
|
|
|
|
|
|
|
|
| |
the state of that functionality.
I have put them all in their own category, and made that category disabled by default.
Differential revision: https://reviews.llvm.org/D31718
llvm-svn: 299587
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
look showed that the target's arch has no core / byte order and so when
AuxVector::AuxVector calls into a dataextractor and sets the byte size to 0,
it asserts. e.g.
m_arch = {
m_triple = (Data = "x86_64--linux", Arch = x86_64, SubArch = NoSubArch, Vendor = UnknownVendor, OS = Linux, Environment = UnknownEnvironment, ObjectFormat = ELF)
m_core = kCore_invalid
m_byte_order = eByteOrderInvalid
m_flags = 0x00000000
m_distribution_id = <no value available>
}
<rdar://problem/31380097>
llvm-svn: 299408
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
After this change a sythetic child provider can generate a special child
named "$$dereference$$" what if present is used when "operator*" or
"operator->" used on a ValueObject. The goal of the change is to make
expressions like "up->foo" work inside the "frame variable" command.
Reviewers: labath, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D31368
llvm-svn: 299251
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Displaying the object pointed by the unique_ptr can cause an infinite
recursion when we have a pointer loop so this change stops that
behavior. Additionally it makes the unique_ptr act more like a class
containing a pointer (what is the underlying truth) instead of some
"magic" class.
Reviewers: labath, jingham
Differential Revision: https://reviews.llvm.org/D31366
llvm-svn: 299249
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: labath, clayborg
Subscribers: jaydeep, bhushan, lldb-commits, slthakur
Differential Revision: https://reviews.llvm.org/D31280
llvm-svn: 299199
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This aims to replace the different decorators we've had on each libc++
test with a single solution. Each libc++ will be assigned to the
"libc++" category and a single central piece of code will decide whether
we are actually able to run libc++ test in the given configuration by
enabling or disabling the category (while giving the user the
opportunity to override this).
I started this effort because I wanted to get libc++ tests running on
android, and none of the existing decorators worked for this use case:
- skipIfGcc - incorrect, we can build libc++ executables on android
with gcc (in fact, after this, we can now do it on linux as well)
- lldbutil.skip_if_library_missing - this checks whether libc++.so is
loaded in the proces, which fails in case of a statically linked
libc++ (this makes copying executables to the remote target easier to
manage).
To make this work I needed to split out the pseudo_barrier code from the
force-included file, as libc++'s atomic does not play well with gcc on
linux, and this made every test fail, even though we need the code only
in the threading tests.
So far, I am only annotating one of the tests with this category. If
this does not break anything, I'll proceed to update the rest.
Reviewers: jingham, zturner, EricWF
Subscribers: srhines, lldb-commits
Differential Revision: https://reviews.llvm.org/D30984
llvm-svn: 299028
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was added to workaround a limitation in LLVM's implementation
of getting the current user's home directory, since it would
only look at the value of $HOME, but we did not want to rely
on that being set so we would also look in the password database.
Adding the ability to look in the password database to LLVM was
a straightforward patch that was submitted in r298513, so since
that is done this test is no longer needed.
llvm-svn: 298519
|
|
|
|
|
|
|
|
|
| |
Only do this when we are debugging an executable, since we
don't have a good way to trace from an ObjectFile back to its
containing executable. Detecting pre-run libs before running
is "best effort" in lldb, but this one is pretty easy.
llvm-svn: 298290
|
|
|
|
|
|
|
| |
Launching a process with shared libraries on remote targets requires a
special dance, which I forgot to do in r297830.
llvm-svn: 297834
|
|
|
|
|
|
|
|
|
| |
It seems that on darwin we are not able to resolve breakpoints in the
test shared library until the process has started. That seems
unfortunate, but it is not the purpose of this test, so work around that
by starting the process before doing the rest of our checks.
llvm-svn: 297830
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
function boundaries
Summary:
This fixes the case where a user tries to set a breakpoint on a source
line outside of any function (e.g. because that code is #ifdefed out, or
the compiler did not emit code for the function, etc.) and we would
silently move the breakpoint to the next function.
Now we check whether the line range of the resolved symbol context
function matches the original line number. We reject any breakpoint
locations that appear to move the breakpoint into a new function. This
filtering only happens if we have full debug info available (e.g. in
case of -gline-tables-only compilation, we still set the breakpoint on
the nearest source line).
Reviewers: jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D30817
llvm-svn: 297817
|
|
|
|
| |
llvm-svn: 296692
|
|
|
|
|
|
|
| |
We don't need to run this test multiple times to check whether we can
read a register.
llvm-svn: 296611
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
There is nothing we can do with the breakpoint once the associated
target becomes deleted. This will make sure we don't hold on to more
resources than we need in this case. In particular, this fixes the case
TestStepOverBreakpoint on windows, where a lingering SBBreakpoint object
causes us to nor unmap the executable file from memory.
Reviewers: clayborg, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D30249
llvm-svn: 296328
|
|
|
|
|
|
|
|
| |
Please look at below differential link for upstream discussion.
Differential revision: https://reviews.llvm.org/D29669
llvm-svn: 296119
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This also removes magic rename code, which caused the channel to be
called "linux" when built on a linux machine, and "freebsd" when built
on a freebsd one, which seems unnecessary - registering a new channel is
sufficiently simple now that if we wish to log something extremely
os-specific, we can just create a new channel. None of the current
categories seem very specific to one OS or another.
Reviewers: emaste, krytarowski
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D30250
llvm-svn: 295954
|
|
|
|
|
|
|
| |
not being picked up; filed <rdar://problem/30645203> to track
the work to investigate this.
llvm-svn: 295804
|
|
|
|
| |
llvm-svn: 295211
|
|
|
|
|
|
|
|
|
| |
Differential Revisions:
https://reviews.llvm.org/D26497 (committed r290168, temporary reverted r290197)
https://reviews.llvm.org/D28945 (fix for Ubuntu tests fail)
https://reviews.llvm.org/D29909 (fix for TestCallThatThrows test fail)
llvm-svn: 295168
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: labath, clayborg
Subscribers: jaydeep, bhushan, lldb-commits, slthakur
Differential Revision: https://reviews.llvm.org/D29215
llvm-svn: 294415
|
|
|
|
|
|
| |
variable we are inspecting.
llvm-svn: 293666
|
|
|
|
|
|
| |
reasonable time.
llvm-svn: 293269
|
|
|
|
|
|
|
|
|
| |
after r276132 so that 'x/4b' would print out a series of 4 8-byte
quantities. Fix that, add a test case.
<rdar://problem/29930833>
llvm-svn: 293002
|
|
|
|
|
|
|
|
| |
Differential Revisions:
https://reviews.llvm.org/D26497 (committed r290168, temporary reverted r290197)
https://reviews.llvm.org/D28945 (fix for Ubuntu tests fail)
llvm-svn: 292930
|
|
|
|
|
|
|
|
|
|
|
|
| |
r290874 enabled the s390x test, which caused the rest of the tests to start
misbehaving. This is because this test switches the selected platform and the
change persists.
This fixes it by explicitly resetting the platform in a similar way to the gcore
tests do. Potentially we should consider re-setting the platform globally
between each test run to better protect tests from each other.
llvm-svn: 290890
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch changes and simplifies the way notes are read from Linux Elf cores.
The current implementation copies the bytes from the notes directly over the lldb structure for 64 bit cores and reads field by field for 32 bit cores. Reading the bytes directly only works if the endianess of the core dump and the platform that lldb are running on matches. The case statements for s390x and x86_64 would would only work on big endian systems and little endian systems respectively. That meant that x86_64 generally worked but s390x didn't unless you were on s390x or another big endian platform.
This patch just reads field by field on all platform and updates the field by field version to allow for those fields which are word size instead of fixed size. It should also slightly simplify adding support for a new Linux platform.
This patch also re-enables the s390x test case in TestLinuxCore.py on all non-s390x platforms as it now passes.
Reviewers: uweigand, clayborg
Differential Revision: https://reviews.llvm.org/D27571
llvm-svn: 290874
|
|
|
|
|
|
|
|
| |
TestNoreturnUnwind fails on arm/aarch32 linux targets.
Bug is already described for x86_64 android targets in llvm.org/pr31192.
llvm-svn: 290821
|