| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
It might have caused some instability on the bots.
llvm-svn: 323845
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Initialize the default value of SymbolFileDWARF uuid with
the appropriately shifted DW_INVALID_OFFSET constant.
This change fixes the collision in the computation of DIE uid
(inside DIERef::GetUID) and incorrect CompileUnit lookup
(because of the misleading cu_offset value).
Test plan: make check-lldb
Differential revision: https://reviews.llvm.org/D42563
llvm-svn: 323832
|
|
|
|
|
|
| |
This is a prerequisite for building each test variant in its own subdirectory.
llvm-svn: 323830
|
|
|
|
|
|
|
|
|
| |
Strings which contain garbage data can trigger an exception in the XUnit
plugin at the UTF-8 decode step because the decode is strict. Use a lax
mode to avoid an exception.
See: https://ci.swift.org/job/oss-lldb-incremental-osx/780
llvm-svn: 323817
|
|
|
|
|
|
|
|
| |
See: https://ci.swift.org/job/swift-lldb-PR-osx/39
llvm.org/PR25934
llvm-svn: 323809
|
|
|
|
| |
llvm-svn: 323808
|
|
|
|
| |
llvm-svn: 323805
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch is the result of a discussion on lldb-dev, see
http://lists.llvm.org/pipermail/lldb-dev/2018-January/013111.html for
background.
For each test (should be eventually: each test configuration) a
separate build directory is created and we execute
make VPATH=$srcdir/path/to/test -C $builddir/path/to/test -f $srcdir/path/to/test/Makefile -I $srcdir/path/to/test
In order to make this work all LLDB tests need to be updated to find
the executable in the test build directory, since CWD still points at
the test's source directory, which is a requirement for unittest2.
Although we have done extensive testing, I'm expecting that this first
attempt will break a few bots. Please DO NOT HESITATE TO REVERT this
patch in order to get the bots green again. We will likely have to
iterate on this some more.
Differential Revision: https://reviews.llvm.org/D42281
llvm-svn: 323803
|
|
|
|
|
|
|
| |
and fix resulting errors. This is a prerequisite for building each
test variant in its own build directory.
llvm-svn: 323789
|
|
|
|
|
|
| |
We also need to be .EXE-aware when searching for the clang binary.
llvm-svn: 323763
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The difference between this and regular LLDB_LOG is that this one clears
the error object unconditionally. This was inspired by the
ObjectFileELF bug (r322664), where the error object was being cleared
only if logging was enabled.
Reviewers: davide, zturner, jingham, clayborg
Subscribers: lldb-commits, emaste
Differential Revision: https://reviews.llvm.org/D42182
llvm-svn: 323753
|
|
|
|
|
|
|
|
|
| |
The logic was incorrect because on windows, we need to look for
yaml2obj.EXE. I implement the search in terms of
distutils.spawn.find_executable, which should handle the platform
differences for us.
llvm-svn: 323744
|
|
|
|
|
|
| |
It fails due to an assertion (if these are enabled).
llvm-svn: 323736
|
|
|
|
| |
llvm-svn: 323723
|
|
|
|
|
|
|
| |
Another step towards enabling unexpected successes as failures
by default.
llvm-svn: 323707
|
|
|
|
|
|
|
|
|
|
|
| |
Fix the Linux plugin lookup path to include appropriate libdir suffix
for the system. To accomplish this, store the value of
LLVM_LIBDIR_SUFFIX in lldb/Host/Config.h as LLDB_LIBDIR_SUFFIX,
and use this variable when defining the plugin path.
Differential Revision: https://reviews.llvm.org/D42317
llvm-svn: 323673
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`num_args` is unsigned integer, declared as below:
```
uint32_t num_args = arg_enum->getChildCount();
```
Comparison with the signed `arg_idx` produces a warning when compiled with
-Wsign-compare flag, this patch addresses this simple issue without affecting
any functionality.
Reviewers: davide, asmith
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D42620
llvm-svn: 323645
|
|
|
|
| |
llvm-svn: 323639
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The ObjectFile class was used to determine the architecture of a running
process by inspecting it's main executable. There were two issues with
this:
- it's in the wrong layer
- the call can be very expensive (it can end up computing the crc of the
whole file).
Since the process is running on the host, ideally we would be able to
just query the data straight from the OS like darwin does, but there
doesn't seem to be a reasonable way to do that. So, this fixes the
layering issue by using the llvm object library to inspect the file.
Since we know the process is already running on the host, we just need
to peek at a few bytes of the elf header to determine whether it's 32-
or 64-bit (which should make this faster as well).
Pretty much the same logic was implemented in
NativeProcessProtocol::ResolveProcessArchitecture, so I delete this
logic and replace calls with GetProcessInfo.
Reviewers: eugene, krytarowski
Subscribers: mgorny, hintonda, lldb-commits
Differential Revision: https://reviews.llvm.org/D42488
llvm-svn: 323637
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Adds new utilities that make it easier to write test cases for lldb acting as a client over a gdb-remote connection.
- A GDBRemoteTestBase class that starts a mock GDB server and provides an easy way to check client packets
- A MockGDBServer that, via MockGDBServerResponder, can be made to issue server responses that test client behavior.
- Utility functions for handling common data encoding/decoding
- Utility functions for creating dummy targets from YAML files
----
Split from the review at https://reviews.llvm.org/D42145, which was a new feature that necessitated the new testing capabilities.
Reviewers: clayborg, labath
Reviewed By: clayborg, labath
Subscribers: hintonda, davide, jingham, krytarowski, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D42195
Patch by Owen Shaw <llvm@owenpshaw.net>
llvm-svn: 323636
|
|
|
|
|
|
|
|
| |
Simplification by removing excessive DWARFCompileUnit references for D40466 .
Differential revision: https://reviews.llvm.org/D42613
llvm-svn: 323586
|
|
|
|
|
|
|
|
| |
Now the function returns `False`, and the caller can take the
appropriate action (in this case, for --executable, reporting
that the file doesn't exist).
llvm-svn: 323566
|
|
|
|
| |
llvm-svn: 323537
|
|
|
|
|
|
|
|
|
|
|
| |
TestLibcxxListLoop - fails because the evil "define private public"
trick does not work with gmodules. The purpose of the test is not to
test debug info parsing so I just mark it as no_debug_info_testcase.
In the long term it may be interesting to write a mock std::list which
will allow us to test bad inputs to data formatters more easily.
TestGModules - seems to be a genuine bug. Filed pr36107 and xfailed.
llvm-svn: 323520
|
|
|
|
|
|
|
|
|
|
| |
This test #include's stdio.h, which, on at least two bots results in a
module import of MacTypes.h (due to weird SDK layering issues), which
causes the test to fail to compile.
Just don't #include stdio.h, as it's not needed for the test.
llvm-svn: 323467
|