| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Python file handling got an overhaul in Python 3, and it affects
the way we have to interact with files. Notably:
1) `PyFile_FromFile` no longer exists, and instead we have to use
`PyFile_FromFd`. This means having a way to get an fd from
a FILE*. For this we reuse the lldb_private::File class to
convert between FILE*s and fds, since there are some subtleties
regarding ownership rules when FILE*s and fds refer to the same
file.
2) PyFile is no longer a builtin type, so there is no such thing as
`PyFile_Check`. Instead, files in Python 3 are just instances
of `io.IOBase`. So the logic for checking if something is a file
in Python 3 is to check if it is a subclass of that module.
Additionally, some unit tests are added to verify that `PythonFile`
works as expected on Python 2 and Python 3, and
`ScriptInterpreterPython` is updated to use `PythonFile` instead of
manual calls to the various `PyFile_XXX` methods.
llvm-svn: 250444
|
|
|
|
|
|
| |
I actually did not want to commit this without review, but I mistyped. :/
llvm-svn: 250412
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On linux, the environment variables for temp directories that lldb checks for are generally not
defined, and the temp directory computation failed. This caused expression evaluation to fall
back to creating "/tmp/lldb-*.expr" debugging files instead of the usual
"$TMP/lldb/pid/lldb-*.expr". Crucially, these files were not cleaned up on lldb exit, which
caused clutter in the /tmp folder, especially on long-running machines (e.g. builtbots). This
commit fixes lldb to use llvm::sys::path::system_temp_directory, which does the same environment
variable dance, but (!) also falls back to the P_tmpdir macro, which is how the temp directory is
defined on linux.
Since the linux temp path computation now succeeds, I needed to also modify Android path
computation to check for actual directory existence, rather then checking whether the operation
failed.
llvm-svn: 250409
|
|
|
|
|
|
|
|
|
| |
Most platforms have "/dev/null". Windows has "nul". Instead of
hardcoding the string /dev/null at various places, make a constant
that contains the correct value depending on the platform, and use
that everywhere instead.
llvm-svn: 250331
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
unknowns
* ArchSpec::MergeFrom() would erroneously promote an unspecified
unknown to a specified unknown when both the ArchSpec and the merged
in ArchSpec were both unspecified unknowns. This no longer happens,
which fixes issues with global module cache lookup in some
situations.
* Added ArchSpec::DumpTriple(Stream&) that now properly prints
unspecified unknowns as '*' and specified unknows as 'unknown'.
This makes it trivial to tell the difference between the two.
Converted printing code over ot using DumpTriple() rather than
building from scratch.
* Fixed up a couple places that were not guaranteeing that an
unspecified unknown was recorded as such.
llvm-svn: 250253
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
/usr/lib/debug on Windows
Summary:
/usr/lib/debug doesn't exist on Windows so there's no point even
attempting to look for symbol files in there.
Reviewers: zturner, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13636
llvm-svn: 250175
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This adds platform code without the cmake/gmake glue to the existing infrastructure.
The missing and incompatibility ptrace(2) bits (existing in FreeBSD) are under active research and development and will be submitted once verified to work.
This code was tested to build and run on NetBSD-current/amd64.
Proper build scripts will be integrated separately as a new commit.
Reviewers: joerg
Subscribers: tfiala, brucem, labath, emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D13334
llvm-svn: 250146
|
|
|
|
|
|
|
|
| |
dirs
This change commits: http://reviews.llvm.org/D13625
llvm-svn: 250093
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
when they introduced android testsuite regressions. Pavel has run the
testsuite against the updated patch and it completes cleanly now.
The original commit message:
Fixing a subtle issue on Mac OS X systems with dSYMs (possibly
introduced by r235737 but I didn't look into it too closely).
A dSYM can have a per-UUID plist in it which tells lldb where
to find an executable binary for the dSYM (DBGSymbolRichExecutable)
- other information can be included in this plist, like how to
remap the source file paths from their build pathnames to their
long-term storage pathnames.
This per-UUID plist is a unusual; it is used probably exclusively
inside apple with our build system. It is not created by default
in normal dSYMs.
The problem was like this:
1. lldb wants to find an executable, given only a UUID
(this happens when lldb is doing cross-host debugging
and doesn't have a copy of the target system's binaries)
2. It eventually calls LocateMacOSXFilesUsingDebugSymbols
which does a spotlight search for the dSYM on the local
system, and failing that, tries the DBGShellCommands
command to find the dSYM.
3. It gets a dSYM. It reads the per-UUID plist in the dSYM.
The dSYM has a DBGSymbolRichExecutable kv pair pointing to
the binary on a network filesystem.
4. Using the binary on the network filesystem, lldb now goes
to find the dSYM.
5. It starts by looking for a dSYM next to the binary it found.
6. lldb is now reading the dSYM over a network filesystem,
ignoring the one it found on its local filesystem earlier.
Everything still *works* but it's much slower.
This would be a tricky one to write up in a testsuite case;
you really need the binary to not exist on the local system.
And LocateMacOSXFilesUsingDebugSymbols will only compile on
Mac OS X - even if I found a way to write up a test case, it
would not run anywhere but on a mac.
One change Greg wanted while I was touching this code was to
have LocateMacOSXFilesUsingDebugSymbols (which could be asked
to find a binary OR find a dSYM) to instead return a ModuleSpec
with the sum total of everything it could find. This
change of passing around a ModuleSpec instead of a FileSpec
was percolated up into ModuleList::GetSharedModule.
The changes to LocateMacOSXFilesUsingDebugSymbols look larger
than they really are - there's a lot of simple whitespace changes
in there.
I ran the testsuites on mac, no new regressions introduced
<rdar://problem/21993813>
llvm-svn: 249755
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When `module_spec.GetFileSpec().GetDirectory().AsCString()` returned a `nullptr` this line caused a segmentation fault:
`std::string module_directory = module_spec.GetFileSpec().GetDirectory().AsCString()`
Some context:
I was remote debugging an executable built with Clang in an Ubuntu VM on my Windows machine using lldb-mi. I copied the executable and nothing else from the Ubuntu VM to the Windows machine.
Then started lldb-server in the Ubuntu VM:
```
./bin/lldb-server gdbserver *:8888 -- /home/enlight/Projects/dbgmits/build/Debug/data_tests_target
```
And ran `lldb-mi --interpreter` on Windows with the following commands:
```
-file-exec-and-symbols C:\Projects\data_tests_target
-target-select remote 192.168.56.101:8888
-exec-continue
```
After which the segmentation fault occurred at the aforementioned line. Inside this method `module_spec.GetFileSpec()` returns an empty `FileSpec` (no dir, no filename), while `module_spec.GetSymbolFileSpec().GetFilename()` returns `"libc-2.19.so"`.
Patch thanks to Vadim Macagon.
Reviewers: brucem, zturner, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13201
llvm-svn: 249387
|
|
|
|
|
|
|
| |
This reverts commit r248985, as it was breaking all remote
expression-evaluating tests (on android at least).
llvm-svn: 248995
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
introduced by r235737 but I didn't look into it too closely).
A dSYM can have a per-UUID plist in it which tells lldb where
to find an executable binary for the dSYM (DBGSymbolRichExecutable)
- other information can be included in this plist, like how to
remap the source file paths from their build pathnames to their
long-term storage pathnames.
This per-UUID plist is a unusual; it is used probably exclusively
inside apple with our build system. It is not created by default
in normal dSYMs.
The problem was like this:
1. lldb wants to find an executable, given only a UUID
(this happens when lldb is doing cross-host debugging
and doesn't have a copy of the target system's binaries)
2. It eventually calls LocateMacOSXFilesUsingDebugSymbols
which does a spotlight search for the dSYM on the local
system, and failing that, tries the DBGShellCommands
command to find the dSYM.
3. It gets a dSYM. It reads the per-UUID plist in the dSYM.
The dSYM has a DBGSymbolRichExecutable kv pair pointing to
the binary on a network filesystem.
4. Using the binary on the network filesystem, lldb now goes
to find the dSYM.
5. It starts by looking for a dSYM next to the binary it found.
6. lldb is now reading the dSYM over a network filesystem,
ignoring the one it found on its local filesystem earlier.
Everything still *works* but it's much slower.
This would be a tricky one to write up in a testsuite case;
you really need the binary to not exist on the local system.
And LocateMacOSXFilesUsingDebugSymbols will only compile on
Mac OS X - even if I found a way to write up a test case, it
would not run anywhere but on a mac.
One change Greg wanted while I was touching this code was to
have LocateMacOSXFilesUsingDebugSymbols (which could be asked
to find a binary OR find a dSYM) to instead return a ModuleSpec
with the sum total of everything it could find. This
change of passing around a ModuleSpec instead of a FileSpec
was percolated up into ModuleList::GetSharedModule.
The changes to LocateMacOSXFilesUsingDebugSymbols look larger
than they really are - there's a lot of simple whitespace changes
in there.
I ran the testsuites on mac, no new regressions introduced
<rdar://problem/21993813>
llvm-svn: 248985
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See:
https://llvm.org/bugs/show_bug.cgi?id=24926
for details. On OS X, when LLDB.framework is
not part of the lldb.dylib path, the supporting
executable path is resolved to be the bin directory
sitting next to the lib directory with the dylib
lives. Not a perfect solution, but we also can't
base it on the executable path since both Python
and the lldb driver can be the executable.
llvm-svn: 248545
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: tfiala, granata.enrico, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13125
llvm-svn: 248466
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This is no longer needed as this file no longer calls backtrace().
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13049
llvm-svn: 248457
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
pthread_setname_np() is a nonstandard GNU extension and isn't available
in every C library. Check before it's usage that GLIBC is available or
that we are targeting Android.
Reviewers: clayborg, ovyalov
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13019
llvm-svn: 248280
|
|
|
|
| |
llvm-svn: 248268
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: ovyalov, clayborg
Subscribers: tberghammer, danalbert, llvm-commits, srhines
Differential Revision: http://reviews.llvm.org/D13016
llvm-svn: 248256
|
|
|
|
|
|
|
|
| |
zturner!
http://reviews.llvm.org/D12984
llvm-svn: 248055
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We use the symbolic link to resolver to find the target of the LLDB shlib
symlink if there is a symlink. This allows us to find shlib-relative resources
even when running under the testsuite, where _lldb.so is a symlink in the Python
resource directory.
Also changed a comment to be slightly more clear about what resolve_path in the
constructor for FileSpec means, since if we were actually using realpath() this
code wouldn't have been necessary.
http://reviews.llvm.org/D12984
llvm-svn: 248048
|
|
|
|
|
|
| |
http://reviews.llvm.org/D12971
llvm-svn: 248017
|
|
|
|
|
|
|
|
| |
Patch by Kamil Rytarowski.
Differential Revision: http://reviews.llvm.org/D12746
llvm-svn: 247568
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: joerg, sas
Subscribers: labath, lldb-commits
Differential Revision: http://reviews.llvm.org/D12661
Change by Kamil Rytarowski <n54@gmx.com>
llvm-svn: 247115
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Build warning caught on NetBSD.
Reviewers: joerg, sas
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12662
Change by Kamil Rytarowski <n54@gmx.com>
llvm-svn: 247114
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
GetOptInc provides getopt(), getopt_long() and getopt_long_only().
Windows (for defined(_MSC_VER)) doesn't ship with all of the getopt(3) family members and needs all of them. NetBSD requires only getopt_long_only(3).
While there fix the code for clang diagnostics.
Author: Kamil Rytarowski
Reviewers: joerg
Subscribers: labath, zturner, lldb-commits
Differential Revision: http://reviews.llvm.org/D12582
llvm-svn: 246843
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: accept4(2) and paccept(2) are nonstandard extensions.
Reviewers: joerg, sas
Subscribers: emaste, sas, lldb-commits
Differential Revision: http://reviews.llvm.org/D12485
Change by Kamil Rytarowski <n54@gmx.com>
llvm-svn: 246787
|
|
|
|
|
|
|
|
|
|
| |
Some tests were failing because the test would try to delete the
file before inferior had exited, but on Windows this will fail by
default unless you specify FILE_SHARE_DELETE when opening the file.
Can't think of a good reason not to do this, so here it is.
llvm-svn: 246682
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When calling find_first_of and find_last_of on a single character,
we can instead just call find / rfind and make our intent more
clear.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12518
llvm-svn: 246609
|
|
|
|
|
|
| |
http://reviews.llvm.org/D12025
llvm-svn: 245639
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
dllexport doesn't work if linking against a static library with its own
copy of snprintf.
Reviewers: zturner
Subscribers: zturner, lldb-commits
Differential Revision: http://reviews.llvm.org/D12206
llvm-svn: 245610
|
|
|
|
| |
llvm-svn: 244936
|
|
|
|
| |
llvm-svn: 244935
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SUMMARY:
Last 3bits of the watchpoint address are masked by the kernel. For example, n is
at 0x120010d00 and m is 0x120010d04. When a watchpoint is set at m, then watch
exception is generated even when n is read/written. To handle this case, instruction
at PC is emulated to find the base address of the load/store instruction. This address
is then appended to the description of the stop-info packet. Client then reads this
information to check whether the user has set a watchpoint on this address.
Reviewers: jingham, clayborg
Subscribers: nitesh.jain, mohit.bhakkad, sagar, bhushan and lldb-commits
Differential Revision: http://reviews.llvm.org/D11672
llvm-svn: 244864
|
|
|
|
|
|
| |
http://reviews.llvm.org/D11256
llvm-svn: 244419
|
|
|
|
|
|
| |
The SB API for major version 340 won't be changing any more.
llvm-svn: 243943
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously embedded interpreters were handled as ad-hoc source
files compiled into source/Interpreter. This made it hard to
disable a specific interpreter, or to add support for other
interpreters and allow the developer to choose which interpreter(s)
were enabled for a particular build.
This patch converts script interpreters over to a plugin-based system.
Script interpreters now live in source/Plugins/ScriptInterpreter, and
the canonical LLDB interpreter, ScriptInterpreterPython, is moved there
as well.
Any new code interfacing with the Python C API must live in this location
from here on out. Additionally, generic code should never need to
reference or make assumptions about the presence of a specific interpreter
going forward.
Differential Revision: http://reviews.llvm.org/D11431
Reviewed By: Greg Clayton
llvm-svn: 243681
|
|
|
|
|
|
| |
Differential revision: http://reviews.llvm.org/D11595
llvm-svn: 243637
|
|
|
|
|
|
|
|
| |
patch by Eugene Zelenko
Differential Revision: http://reviews.llvm.org/D11429
llvm-svn: 243399
|
|
|
|
|
|
|
|
|
| |
dSYMs, or reading binaries out of memory to the 'Host' log channel.
There's more to be done here, both for Mac and for other platforms,
but the initial set of new loggings are useful enough to check in
at this point.
llvm-svn: 243200
|
|
|
|
|
|
|
|
|
|
|
|
| |
adding them
to the path remappings.
Also don't add the paths to the path mapping when DebugSymbols tells up about files, since
we'll just do that again when we read in the dSYM.
<rdar://problem/21986208>
llvm-svn: 243181
|
|
|
|
|
|
|
|
| |
the Host channel.
http://reviews.llvm.org/D11497
llvm-svn: 243175
|
|
|
|
| |
llvm-svn: 243174
|
|
|
|
|
|
|
|
| |
don't set off firewall protections.
<rdar://problem/17897318>
llvm-svn: 243118
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This replaces (void)x; usages where they x was subsequently
involved in an assertion with this macro to make the
intent more clear.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11451
llvm-svn: 243074
|
|
|
|
|
|
| |
multi-threaded test case. The error would cause an assertion that could cause lldb to crash when unlocking a mutex returned an error because it was in use.
llvm-svn: 243067
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Fix a bunch of typos.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11386
llvm-svn: 242856
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This commit integrates MainLoop into NativeProcessLinux. By registering a SIGCHLD handler with
the llgs main loop, we can get rid of the special monitor thread in NPL, which saves as a lot of
thread ping-pong when responding to client requests (e.g. qThreadInfo processing time has been
reduced by about 40%). It also makes the code simpler, IMHO.
Reviewers: ovyalov, clayborg, tberghammer, chaoren
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11150
This is a resubmission of r242305 after it was reverted due to bad interactions with the stdio
thread.
llvm-svn: 242783
|
|
|
|
|
|
|
|
| |
I have observed an increased flakyness in the buildbots. I suspect something was relying on the
fact that Pipe::Write had an implicit timeout of 1s, which this commit has removed. Reverting
while I investigate.
llvm-svn: 242767
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This commit adds a WriteWithTimeout method to time Pipe class, analogous to the existing
ReadWithTimeout(). It also changes the meaning of passing zero as a timeout value. Previously,
zero was used as an infinite timeout value. Now, the meaning of zero timeout to return the data
avaiable without sleeping (basically, a non-blocking operation). This makes the behaviour of Pipe
consistent with the Communication/Connection classes. For blocking operatios with infinite
timeout, I introduce a special constant for this purpose.
Reviewers: ovyalov, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11358
llvm-svn: 242764
|
|
|
|
|
|
| |
http://reviews.llvm.org/D11356
llvm-svn: 242753
|