| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
This only worked on MacOS, which now ships a newer version of
python without this bug. As such, we don't leak the fd, and
this test is not needed anymore (as it also hardcoded the python
version in the check).
llvm-svn: 324743
|
|
|
|
| |
llvm-svn: 324730
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Right now the test client is not parsing register values correctly,
which is manifesting itself in one test failing on 32-bit architectures
(pr36013). This parses the information from the qRegisterInfo packets
and stores it in the client, which will enable fixing the parsing in a
follow up commit.
I am also adding a new templated SendMessage overload, which enables one
to send a message get a parsed response in a single call.
Reviewers: eugene, davide
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D43076
llvm-svn: 324722
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is combination of following changes,
- Resolve function symbols in PDB symbol file. `lldb-test symbols` will display information about function symbols.
- Implement SymbolFilePDB::FindFunctions methods. On lldb console, searching function symbol by name and by regular expression are both available.
- Create lldb type for PDBSymbolFunc.
- Add tests to check whether functions with the same name but from different sources can be resolved correctly.
Reviewers: zturner, lldb-commits
Reviewed By: zturner
Subscribers: amccarth, labath, llvm-commits
Differential Revision: https://reviews.llvm.org/D42443
llvm-svn: 324707
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: zturner, lldb-commits, labath
Reviewed By: zturner
Subscribers: jingham, labath, davide, llvm-commits
Differential Revision: https://reviews.llvm.org/D43059
llvm-svn: 324672
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Update makefiles to specify -fPIC in Makefile.rules and only throw -fPIC when building a shared library. This change is necessary to allow building the lldb tests on Windows where -fPIC is not a valid option.
Update a few places to Python 3.x syntax
Reviewers: zturner, lldb-commits
Reviewed By: zturner
Subscribers: stella.stamenova, labath, llvm-commits
Differential Revision: https://reviews.llvm.org/D42994
llvm-svn: 324671
|
|
|
|
|
|
|
|
| |
TODO: Add a separate testcase testing *only* Foundation implementation details!
<rdar://problem/37252738>
llvm-svn: 324655
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The test was trying to reproduce a bug in handling of two concurrent
events, which was impossible to do reliably in a black-box style test.
In practice, this meant the test was only ever failing on remote
targets, as these were slow enough to trigger this.
Fortunately, we now have the ability to mock the server side of the
connection, which means we can simulate the failure deterministically,
so I rewrite the test to use the new gdb-client framework.
I've needed to add a couple of new packets to the mock server to be able
to do this. Instead of trying to guess how a "typical" gdb-client test
will want to handle this, I throw an exception in the implementation to
force the user to override them (the packets are only sent if the test
explicitly performs some action which will trigger them, so a basic test
which e.g. does not need the "continue" functionality will not need to
implement them).
Reviewers: owenpshaw
Subscribers: srhines, lldb-commits
Differential Revision: https://reviews.llvm.org/D42959
llvm-svn: 324590
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLDB_TEST_CXX_COMPILER
Summary:
LLDB_TEST_COMPILER is not a valid option for CMake for LLDB. There are instead two properties LLDB_TEST_C_COMPILER and LLDB_TEST_CXX_COMPILER. Update the documents accordingly to reflect the correct information.
Reviewers: zturner, lldb-commits
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D43061
llvm-svn: 324564
|
|
|
|
|
|
| |
Makefile has unix magic and thus not working on windows.
llvm-svn: 324558
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is a small change towards running the LLDB unit tests on Windows (still WIP).
Builds that use make do not point to specific configurations. However, builds with multiple configurations such as Visual Studio on Windows need the configuration (release/debug/etc) as part of the path so the binaries produced by clang are placed in the correct directory for the configuration.
Reviewers: zturner, lldb-commits, labath
Reviewed By: labath
Subscribers: labath, mgorny, hintonda, llvm-commits
Differential Revision: https://reviews.llvm.org/D42990
llvm-svn: 324555
|
|
|
|
|
|
| |
(still can't get over those Emacs habits...)
llvm-svn: 324509
|
|
|
|
|
|
|
|
|
| |
The change in r324488 dropped the existing category attribute in for
instance methods. This patch corrects that.
Differential revision: https://reviews.llvm.org/D43024
llvm-svn: 324492
|
|
|
|
|
|
|
|
|
| |
Inlined tests have a test function that is actually an instance method,
which requires a slightly different approach when it comes to setting
the category attribute. The attribute must be set on the actual
function, rather than on a particular instance.
llvm-svn: 324488
|
|
|
|
|
|
| |
It is unused, and the underlying llvm function has been removed as well.
llvm-svn: 324472
|
|
|
|
|
|
|
|
|
| |
SPI call to to find its own shared cache's UUID. On newer sytems we
need to use the a new SPI which will return the UUID directly.
<rdar://problem/36625871>
llvm-svn: 324437
|
|
|
|
| |
llvm-svn: 324400
|
|
|
|
| |
llvm-svn: 324396
|
|
|
|
|
|
|
|
|
|
| |
Now incorrect type argument that looks like T<A><B> doesn't
cause an assert, but just a parsing error.
Bug: 36224
Differential Revision: https://reviews.llvm.org/D42939
llvm-svn: 324380
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
lock file
This patch creates a <test>.dwarf, <test>.dwo, etc., build directory for each testcase variant.
Most importantly, this eliminates the need for the per-test lock file in the source directory.
Tests that are marked as NO_DEBUG_INFO_TESTCASE and build with
buildDefault() are built in a <test>.default build directory.
Differential Revision: https://reviews.llvm.org/D42763
llvm-svn: 324368
|
|
|
|
| |
llvm-svn: 324293
|
|
|
|
| |
llvm-svn: 324288
|
|
|
|
|
|
|
|
|
| |
GDBRemoteCommunicationServerCommon::Handle_qHostInfo
to use Mach-O cpu types instead of the ArchSpec enum value, and handle the case
of bridgeos.
llvm-svn: 324287
|
|
|
|
| |
llvm-svn: 324281
|
|
|
|
|
|
|
|
| |
(a while ago).
<rdar://problem/20416388>
llvm-svn: 324280
|
|
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D42891
llvm-svn: 324275
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GetModuleSpecifications_EarlySectionHeaders was generated
Davide pointed out this would be useful if the file ever needs to be
regenerated (and I certainly agree).
I also replace the test binary with a slightly smaller one -- I intended
to do this in the original commit, but I forgot to add it to the patch
as I was juggling several things at the same time.
llvm-svn: 324256
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ObjectFileELF::GetModuleSpecifications contained a lot of tip-toing code
which was trying to avoid loading the full object file into memory. It
did this by trying to load data only up to the offset if was accessing.
However, in practice this was useless, as 99% of object files we
encounter have section headers at the end, so we would load the whole
file as soon as we start parsing the section headers.
In fact, this would break as soon as we encounter a file which does
*not* have section headers at the end (yaml2obj produces these), as the
access to .strtab (which we need to get the section names) was not
guarded by this offset check.
As this strategy was completely ineffective anyway, I do not attempt to
proliferate it further by guarding the .strtab accesses. Instead I just
lead the full file as soon as we are reasonably sure that we are indeed
processing an elf file.
If we really care about the load size here, we would need to reimplement
this to just load the bits of the object file we need, instead of
loading everything from the start of the object file to the given
offset. However, given that the OS will do this for us for free when
using mmap, I think think this is really necessary.
For testing this I check a (tiny) SO file instead of yaml2obj-ing it
because the fact that they come out first is an implementation detail of
yaml2obj that can change in the future.
llvm-svn: 324254
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Various changes in logging from log->Printf() to generic LLDB_LOG().
Sponsored by <The NetBSD Foundation>
Reviewers: labath, joerg
Reviewed By: labath
Subscribers: llvm-commits, lldb-commits
Differential Revision: https://reviews.llvm.org/D42912
llvm-svn: 324251
|
|
|
|
|
|
|
| |
Currently, our behavior when installing symlinks on the remote target is
broken (pr36237).
llvm-svn: 324236
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We cannot call process_up->SetState() inside
the NativeProcessNetBSD::Factory::Launch
function because it triggers a NULL pointer
deference.
The generic code for launching a process in:
GDBRemoteCommunicationServerLLGS::LaunchProcess
sets the m_debugged_process_up pointer after
a successful call to m_process_factory.Launch().
If we attempt to call process_up->SetState()
inside a platform specific Launch function we
end up dereferencing a NULL pointer in
NativeProcessProtocol::GetCurrentThreadID().
Use the proper call process_up->SetState(,false)
that sets notify_delegates to false.
Sponsored by <The NetBSD Foundation>
Reviewers: labath, joerg
Reviewed By: labath
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D42868
llvm-svn: 324234
|
|
|
|
|
|
|
| |
We've had a bug (fixed by https://reviews.llvm.org/D42828) where the
thread name was being read incorrectly. Add a test for this behavior.
llvm-svn: 324230
|
|
|
|
|
|
|
|
| |
This test was marked as an expected failure because of PR20231 but it
seems to consistently result in an unexpected success across the bots.
Let's try to re-enable this test again.
llvm-svn: 324227
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This changes the way we store the debug info variant to make it
available earlier in the test bringup: instead of it being set by the
test wrapper method, it is set as a *property* of the wrapper method.
This way, we can inspect it as soon as self.testMethodName is
initialized. The retrieval is implemented by a new function
TestBase.getDebugInfo(), and all that's necessary to make it work is to
change self.debug_info into self.getDebugInfo().
While searching for debug_info occurences i noticed that TestLogging is
being replicated for no good reason, so I removed the replication there.
Reviewers: aprantl, jingham
Subscribers: eraman, JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D42836
llvm-svn: 324226
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I have found LLDB cannot find separate debug info of Fedora /usr/bin/gdb.
It is because:
lrwxrwxrwx 1 root root 14 Jan 25 20:41 /usr/bin/gdb -> ../libexec/gdb*
-rwxr-xr-x 1 root root 10180296 Jan 25 20:41 /usr/libexec/gdb*
ls: cannot access '/usr/lib/debug/usr/bin/gdb-8.0.1-35.fc27.x86_64.debug': No such file or directory
-r--r--r-- 1 root root 29200464 Jan 25 20:41 /usr/lib/debug/usr/libexec/gdb-8.0.1-35.fc27.x86_64.debug
FYI that -8.0.1-35.fc27.x86_64.debug may look confusing, it was always just
.debug before.
Why is /usr/bin/gdb a symlink is offtopic for this bugreport, Fedora has it so
for some reasons.
It is always safest to look at the .debug file only after resolving all
symlinks on the binary file.
Differential revision: https://reviews.llvm.org/D42853
llvm-svn: 324224
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I have found the lookup by build-id
(when lookup by /usr/lib/debug/path/name/exec.debug failed) does not work as
LLDB tries the build-id hex string in uppercase but Fedora uses lowercase.
xubuntu-16.10 also uses lowercase during my test:
/usr/lib/debug/.build-id/6c/61f3566329f43d03f812ae7057e9e7391b5ff6.debug
Differential revision: https://reviews.llvm.org/D42852
llvm-svn: 324222
|
|
|
|
|
|
|
|
| |
in debugserver. This is already set this way in the lldb
project files but not in debugserver. Updating for
consistency.
llvm-svn: 324158
|
|
|
|
|
|
|
|
|
|
|
|
| |
into a std::string so we don't run off the end of the array when
there is no nul byte in ProcessElfCore::parseLinuxNotes.
Found with ASAN testing.
<rdar://problem/37134319>
Differential revision: https://reviews.llvm.org/D42828
llvm-svn: 324156
|
|
|
|
|
|
| |
for run_to_{source,name}_breakpoint.
llvm-svn: 324119
|
|
|
|
|
|
| |
directory.
llvm-svn: 324115
|
|
|
|
|
|
|
|
|
|
| |
LLDB queries Spotlight to locate .dSYM bundles based on the UUID
embedded in a binary, and because the UUID is a hash of filename and
.text section, there *will* be conflicts inside $BUILD_DIR.
This should fix the broken green dragon bots.
llvm-svn: 324019
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove obsolete measurements.
This check in requires at least 10.11
Reviewed: Jason Molenda, Jim Ingham
<rdar://problem/37047106> Xcode Memory gauge should show the jetsam ledger footprint rather than anonymous
llvm-svn: 324013
|
|
|
|
|
|
|
|
| |
Using the "run_to_{source,name}_breakpoint will allow us to remove
a lot of boiler-plate from the testsuite. We mostly use source
breakpoints, but some tests use by name ones so this was needed.
llvm-svn: 324010
|
|
|
|
| |
llvm-svn: 324008
|
|
|
|
|
|
|
| |
This fails regardless of the android architecture or compiler used. The
important bit is the mismatch in path separators.
llvm-svn: 323974
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The mock server was sending acks back in response to spurious acks from
the client, but the client was not prepared to handle these. Most of the
time this would work because the only time the client was sending
unsolicited acks is after the initial connection, and there reply-ack
would get ignored in the "flush all packets from the server" loop which
came after the ack. However, this loop had only a 10ms delay, and
sometimes this was not enough to catch the reply (which meant the
connection got out of sync, and test failed).
Since this behavior not consistent with how lldb-server handles this
situation (it just ignores the ack), I fix the mock server to do the
same.
llvm-svn: 323953
|
|
|
|
| |
llvm-svn: 323917
|
|
|
|
|
|
|
| |
As of yesterday, tests need to use self.getBuildArtifact() to get the
built executable.
llvm-svn: 323884
|
|
|
|
|
|
|
| |
This recommits the patch, now that I verified that the bot instability
is due to something else. Sorry for the noise.
llvm-svn: 323879
|
|
|
|
|
|
|
|
|
| |
We started passing the "all" target to make, which rendered the
"localall" trick in this Makefile inoperable.
I implement the strip step differently, and also reformat the Makefile.
llvm-svn: 323855
|