vendors & oses, especially on Apple, to handle the new environment
where we have more than macosx or ios (now we have watchos and tvos).
llvm-svn: 252264
Author: Sean Callanan <scallanan@apple.com>
Date: Tue Jun 23 13:52:24 2015 -0700
Memory history should not crash if it can't inspect its data. Added
error handling.
<rdar://problem/21231304>
llvm-svn: 252252
Summary:
The reason for it is limit of detecting ncurses on various systems. For
example, Ubuntu ships with <curses.h> and linkage from <ncurses.h>, <ncurses.h>
isn't detected by CMake. Detecting `<curses.h>` on NetBSD is reusing
conflicting header from the host curses(8) and pkgsrc's ncurses library.
ncurses ships on most (till conflicting) systems with curses.h. On NetBSD it
might be conflicting, so the ncurses headers are installed with pkgsrc to a
subdirectory "ncurses/".
Patch by Kamil Rytarowski. Thanks!
Reviewers: clayborg
Subscribers: youri, akat1, brucem, joerg, lldb-commits
Differential Revision: http://reviews.llvm.org/D14037
llvm-svn: 252250
so when it is run on a kext (which won't activate
any platform plugins), you'll get a warning message
which may be helpful to the user.
llvm-svn: 252245
Summary:
This does a broad first pass on cleaning up a lot of the noise when
using pylint on these scripts. It mostly addresses issues of:
* Mixed tabs and spaces.
* Trailing whitespace.
* Semicolons where they aren't needed.
* Incorrect whitespace around () and [].
* Superfluous parentheses.
There will be subsequent patches with further changes that build
upon these.
Reviewers: zturner, domipheus
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14375
llvm-svn: 252244
at Apple, called by the DebugSymbols private framework to
find a dSYM for a UUID on mac) to include the latest
args we need to use when looking for kernel binaries etc.
llvm-svn: 252235
is running under System Integrity Protection on
Mac OS X 10.11. The rootless_allows_task_for_pid() spi
(see debugserver RNBRemote.cpp) is the final SPI that
is used for this - should add support for that too at
some point.
llvm-svn: 252228
in places where we check for Triple::IOS. They're mostly the same as far
as lldb is conerned.
.
Also add a base cass implementation for Process::IsAlive - Greg added this
last year but it didn't get upstreamed.
llvm-svn: 252227
Summary:
This is a resubmission of r252179, but correctly ignores the source
files for other platforms.
Reviewers: granata.enrico, tberghammer, zturner, jingham
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14389
llvm-svn: 252205
LLDB could otherwise get confused if it is (for example) in a
root that is meant to install into an Xcode.app but hasn't
been installed yet. That way Xcode can fall back to the real
Xcode.app rather than trying to look for resources inside the
root.
llvm-svn: 252198
Absolute imports were introduced in Python 2.5 as a feature
(e.g. from __future__ import absolute_import), and made default
in Python 3.
When absolute imports are enabled, the import system changes in
a couple of ways:
1) The `import foo` syntax will *only* search sys.path. If `foo`
isn't in sys.path, it won't be found. Period. Without absolute
imports, the import system will also search the same directory
that the importing file resides in, so that you can easily
import from the same folder.
2) From inside a package, you can use a dot syntax to refer to higher
levels of the current package. For example, if you are in the
package lldbsuite.test.utility, then ..foo refers to
lldbsuite.test.foo. You can use this notation with the
`from X import Y` syntax to write intra-package references. For
example, using the previous locationa s a starting point, writing
`from ..support import seven` would import lldbsuite.support.seven
Since this is now the default behavior in Python 3, this means that
importing from the same directory with `import foo` *no longer works*.
As a result, the only way to have portable code is to force absolute
imports for all versions of Python.
See PEP 0328 [https://www.python.org/dev/peps/pep-0328/] for more
information about absolute and relative imports.
Differential Revision: http://reviews.llvm.org/D14342
Reviewed By: Todd Fiala
llvm-svn: 252191
It was deprecated even in 2.7, but not removed until 3.x. os.walk
provides all of the same functionality and is the correct way to
do this now.
llvm-svn: 252127
This follows the spirit of a previous patch which did essentially
the same thing. In Python 3, when you use Popen.communicate(),
you get back a bytes object which cannot normally be treated as
a string. We could decode this manually, but universal_newlines=True
does this automatically, and there's no disadvantage to doing so
even on Python 2. So just enable it always.
llvm-svn: 252126
This allows for command-line debugging of iOS simulator binaries (as long as UI is not required, or a full UI simulator has previously been otherwise launched), as well as execution of the LLDB test suite on the iOS simulator
This is known to compile on OSX 10.11 GM - feedback from people on other platforms and/or older versions of OSX as to the buildability of this code is greatly appreciated
llvm-svn: 252112
callers had to do this by hand and we ended up never actually adding initial arguments and then
reusing them by passing in the struct address separately, so the distinction wasn't needed.
llvm-svn: 252108
Python 3 introduces the `timeout` keyword argument on Popen.wait().
If our patched version doesn't support keyword arguments, then when
the internal Python implementation attempts to call wait() with the
keyword argument, things will explode.
Such as my head, after I finally figured out what was happening.
llvm-svn: 252092
LLDB recently started supporting LLDB.framework without a
debugserver in it. When that happens, the Xcode-included debugserver
is searched for and used. This change fixes the code that looks for
Xcode when the housing process is not Xcode. In particular, this
addresses the problem where python is running the test suite and
the LLDB.framework does not contain a debugserver.
llvm-svn: 252059
This reverts commit e59c95ca936f5a0a8abb987b8605fd8bf82b03b6.
This was a mistake on my part. The real problem was with my
environment. I was using a release interpreter to try to load
my debug extension module. I noticed this after I finally managed
to get into my extension module's init method, and then it segfaulted
with heap errors due to mismatched CRT (debug vs. release)
llvm-svn: 252030
In Python 2, a debug extension module required an _d suffix, so
for example the extension module `_lldb` would be backed by the file
`_lldb_d.pyd` if built in debug mode, and `_lldb.pyd` if built in
release mode. In Python 2, although undocumented, this seems to
no longer be the case, and even for a debug extension module, the
interpreter will only look for the `_lldb.pyd` name.
llvm-svn: 252026
By default in Python 3, check_output() returns a program's output as
an encoded byte sequence. This means it returns a Py3 `bytes` object,
which cannot be compared to a string since it's a different fundamental
type.
Although it might not be correct from a purist standpoint, from a
practical one we can assume that all output is encoded in the default
locale, in which case using universal_newlines=True will decode it
according to the current locale. Anyway, universal_newlines also
has the nice behavior that it converts \r\n to \n on Windows platforms
so this makes parsing code easier, should we need that. So it seems
like a win/win.
llvm-svn: 252025
I am not adding a test case for this since I don't know how portable the __fp16 type is between compilers and I don't want to break the test suite.
<rdar://problem/22375079>
llvm-svn: 252012
This patch actually introduces a dependency from unittest2 to
six. This should be ok since both packages are in our own
repo, and we assume a sys.path of the top-level script that
can find the third party packages. So unittest2 should be
able to find six.
llvm-svn: 251983
Let the editor also clean up whitespace for that file.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13816
llvm-svn: 251979
unittest2 was using print statements in a few places, and also
using the `cmp` function (which is removed in Python 3). Again,
we need to stop using unittest2 and using unittest instead, but
this seems like an easier route for now.
llvm-svn: 251978
Old-style syntax: `except Exception, e:`
New-style syntax: `except Exception as e:`
These two statements are identical, except that the former has
been deprecated for may versions, and was removed in Python 3.
This converts everything to use the new syntax (which also works
in Python 2). I had to convert unittest2 as well. What we really
need to do is just delete unittest2, and use unittest instead since
it is a standard module that ships with every Python distribution.
But this is the path of least resistance for now, although at
some point we will really need to do it.
llvm-svn: 251968
This module was originally intended to be imported by top-level
scripts to be able to find the LLDB packages and third party
libraries. Packages themselves shouldn't need to import it,
because by the time it gets into the package, the top-level
script should have already done this. Indeed, it was just
adding the same values to sys.path multiple times, so this
patch is essentially no functional change.
To make sure it doesn't get re-introduced, we also delete the
`use_lldb_suite` module from `lldbsuite/test`, although the
original copy still remains in `lldb/test`
llvm-svn: 251963
The `commands` module was deprecated in 2.7 and removed in 3.x.
As a workaround, we introduce a new module `seven` in
lldbsuite.support, and write helper functions in there that delegate
to the commands module if it is available, and re-implement their
functionality for cases where it is not available.
llvm-svn: 251959
Summary:
The code which was preventing the usage of the OS plugin while detach is in
progress also prevented us to update the thread list correctly. This resulted
in an empty thread list, which confused the detaching logic. Change the
condition do only do what it says (disable the usage of the OS plugin).
Reviewers: clayborg, jingham
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14201
llvm-svn: 251932
Summary:
The solution to bug 24074,rL249673 needed
to parse the function information from the Dwarf in order
to set the SymbolContext. For that, GetFunction was called
for the parent in GetTypeForDIE, which parses the
ChildParameters and in the flow, GetTypeForDIE was called
for one of the sibling die and so an infinite
loop was triggered by calling GetFunction repeatedly for the
same function.
The changes in this revision modify the GetTypeForDIE to only
resolve the function context in the Type Lookup flow and so
prevent the infinite loop.
A testcase has also been added to check for regression in the
future and a test vector had been added to the testcase of
24074.
Reviewers: jingham, tberghammer, clayborg
Differential Revision: http://reviews.llvm.org/D14202
llvm-svn: 251917
For convenience, we had added the folder that dotest.py was in
to sys.path, so that we could easily write things like
`import lldbutil` from anywhere and any test. This introduces
a subtle problem when using Python's package system, because when
unittest2 imports a particular test suite, the test suite is detached
from the package. Thus, writing "import lldbutil" from dotest imports
it as part of the package, and writing the same line from a test
does a fresh import since the importing module was not part of
the same package.
The real way to fix this is to use absolute imports everywhere. Instead
of writing "import lldbutil", we need to write "import
lldbsuite.test.util". This patch fixes up that and all other similar
cases, and additionally removes the script directory from sys.path
to ensure that this can't happen again.
llvm-svn: 251886
This has apparently been broken since June, but only on non-Windows.
Perhaps nobody noticed it because if the symlink is already there
it won't try to re-create it, and nobody ever tried doing a clean
build.
In any case, I will let the original author attempt to fix this if
he is still interested. the problem is that in the normal case
of not setting BUILD_SHARED_LIBS and simply running ninja, it would
link _lldb.so to a non-existent location, creating a dangling
symlink.
llvm-svn: 251840
I think the underlying problem was fixed by r251819, but I can't
reproduce the problem. So this is to check whether it does in
fact fix the problem.
llvm-svn: 251822
The Go interpreter doesn't JIT or use LLVM, so this also
moves all the JIT related code from UserExpression to a new class LLVMUserExpression.
Differential Revision: http://reviews.llvm.org/D13073
Fix merge
llvm-svn: 251820
packages/Python/lldbsuite is now a Python package, and it relies
on its __init__.py being called to do package-level initialization.
If you exec packages/Python/lldbsuite/dotest.py directly, you won't
get this package level initialization, and things will fail. But
without this patch, this is exactly what dosep itself does. To
launch the multi-processing fork, it was hardcoding a path to
dotest.py and exec'ing it from inside the package.
The fix here is to get the path of the top-level script, and
then exec'ing that instead. A more robust solution would involve
refactoring the code so that dosep execs some internal script that
imports lldbsuite, but that's a bit more involved.
Differential Revision: http://reviews.llvm.org/D14157
Reviewed by: Todd Fiala
llvm-svn: 251819
Summary:
As per the following link, the "--" separator can appear between the options
and parameters of any MI command. Previously this separator was only
handled by the `-data-disassemble` MI command. I have moved the relevant
code into `CMICmdBase` so that any MI command can handle the
aforementioned separator.
https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Input-Syntax.html#GDB_002fMI-Input-Syntax
Reviewers: ki.stfu
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14197
llvm-svn: 251793
I don't think anything has changed recently - the test was always flaky, but
only very rarely. Still, it is causing noise in the buildbots.
llvm-svn: 251699
These are two simple tests that make sure single line and
multiline content are processed and received by Editline.cpp.
Fancier tests to come...
llvm-svn: 251681
It turns out that lldbtest_config was being imported locally to "lldbsuite.test" instead of globally, so when the test cases got individually brought by a global import via __import__ by unittest2, they did not see the lldbtest_config import, and ended up importing a new separate copy of it, with lldbExec unset
This is a simple hackaround that brings lldbtest_config to global visibility and makes sure the configuration data is correctly shared
llvm-svn: 251678
This is slightly harder to test because formatters cannot be added to language categories, so deletions are irreversible (in a debugger run)
I plan to add a test case soon, but I need to think about the right approach to obtain one
llvm-svn: 251660
Summary:
I observed that eclipse was passing --thread-group for many other commands
then we are currently handling. Looking at the MI documentation, the
following link states that each MI command accept the --thread and
--frame option. Looking at the GDB implementation, it seems that apart
from these 2, --thread-group is also handled the same way.
https://sourceware.org/gdb/onlinedocs/gdb/Context-management.html#Context-management
So instead of handling those arguments in every comamnds, I have moved
them into the base class and removed them from elsewhere. Now any command
can use these arguments. The patch seems big but most of the changes are
mechanical.
Reviewers: ki.stfu
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14177
llvm-svn: 251636
The test was verifying that the pid of the child is not equal to its process
group by searching for text substrings. This failed in the rare cases when the
pid actually *was* a substring of the process group (even though they were not
equal).
Change the test to use SB API and do proper numeric comparisons.
llvm-svn: 251626
and decided to not commit the change, but accidentally committed
it anyway.
This was based on a static analysis complaint; it thought there
was a code path where AdbClient::PushFile would call AdbClient::ReadSyncHeader
and AdbClient::ReadSyncHeader wouldn't set data_len. But in that
case, the Error object returned will be Fail and we won't use
the data_len or response_id contents.
llvm-svn: 251580
StackFrame * (StackFrame is an ExecutionContextScope.) That allows you to call an
expression on a particular Thread, but not using the context of any particular frame.
That in turn is useful for injecting utility functions that don't actually depend on
locals/self/etc of the current frame.
I also had to include StackFrame.h in a couple of places so the compiler knew
how to downcast StackFrame to ExecutionContextScope.
<rdar://problem/22852953>
llvm-svn: 251564
It's complaining that it doesn't under the "import" command, so
I guess I need this hashbang at the beginning so that it knows
it's a Python script.
llvm-svn: 251544
To do this I added a few new ways to determine the OS from PT_NOTE notes in the ELF file:
1 - Look for "LINUX" notes which indicate "linux" should be the OS
2 - Look through the "CORE" notes with NT_FILE as the type and sniff data from the paths listed in this section. On Ubuntu they contain "/lib/x86_64-linux-gnu" which has the triple and allows us to set "linux" as the OS in the architecture returned from ObjectFileELF::GetArchitecture().
Setting the OS correctly allows us to get the triple correct so we can extract registers without asserting and killing LLDB.
Also use the data from the NT_FILE to set the main executable if one isn't set in ProcessElfCore::DoLoadCore().
llvm-svn: 251537
This is the conclusion of an effort to get LLDB's Python code
structured into a bona-fide Python package. This has a number
of benefits, but most notably the ability to more easily share
Python code between different but related pieces of LLDB's Python
infrastructure (for example, `scripts` can now share code with
`test`).
llvm-svn: 251532
Summary:
This breaks when using a symlink from llvm/tools/lldb to the lldb source
tree, instead of cloning directly as a child. With this change, we can
build properly, even when using links.
Reviewers: dawn, brucem, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14089
llvm-svn: 251530
Summary:
Virtual dynamic shared objects, or vdso files were
not loaded for Linux OS.In Bug 17384 the call
stack could not be unwinded from functions
residing in the vdso object.
This commit adds support for loading such files by
reading the Aux vectors since a vdso is invisibily
mapped to the inferiors address space and the
actual file is not present in the filesystem. The
presence of the vdso is detected by inspecting
the Aux vector for AT_SYSINFO_EHDR tag.
Reviewers: lldb-commits, ovyalov, tberghammer
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14118
llvm-svn: 251505
The idea behind this patch is to expose the meat of
LLDB's Python infrastructure (test suite, scripts, etc)
as a single package. This makes reusability and code
sharing among sub-packages easy.
Differential Revision: http://reviews.llvm.org/D14131
llvm-svn: 251460
This code was modifying the cursor and then expecting the editline
API call to see the effect for the next operation. This is misusing
the API. Newer editlines break on this code, fixed by this.
llvm-svn: 251457
* Remove an unneccessary re-computaion on arch spec from the ELF file
* Use a local cache to optimize name based section lookups in symtab
parsing
* Optimize C++ method basename validation with replacing a regex with
hand written code
These modifications reduce the time required to parse the symtab from
large applications by ~25% (tested with LLDB as inferior)
Differential revision: http://reviews.llvm.org/D14088
llvm-svn: 251402
Summary:
This change deprecates -m/+m dotest options (the options are still recognized but they print an
error message pointing to the new options) and adds a new lldb-mi test category instead. To just
run lldb-mi tests, use '-G lldb-mi'. To skip lldb-mi tests, use '--skip-category lldb-mi'. All
lldb-mi tests are marked as such using the getCategories method on the base MiTestCaseBase class
and the @lldbmi_test decorator is not needed. In case one still needs to annotate a specific test
function as an lldb-mi test, one can use the @add_test_categories(['lldb-mi']) decorator to
achieve that.
Reviewers: tfiala, dawn, ki.stfu, abidh
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14060
llvm-svn: 251400
Summary:
Gdb-remote's async thread sent out the eBroadcastBitRunPacketSent message *before* actually
sending out the continue packet. Since it's this message the actually triggers the public state
transition, it could happen (and it did happen in TestAttachResume, which does an "process
interrupt" right after a continue) that we attempt to stop the inferior before it was actually
started (which obviously did not end well). This fixes the problem by moving the broadcast after
the packet was actually sent.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14083
llvm-svn: 251399
On some combination of platform and c++ library, this dependency was causing the test to fail for reasons tangential to its real objective
llvm-svn: 251368
Summary:
This does not have any functionnal difference but I found myself
searching for 'struct RegisterInfo$' to find a definition and couldn't
find it. The version without typedef seems more common so let's try and
be consistent.
Reviewers: clayborg, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14091
llvm-svn: 251351
On UNIX (but not Darwin) the username needs to be respected when creating a
temporary module directory, so that different users don't pollute each others'
module caches.
llvm-svn: 251340
Python 3 has a different syntax for octal literals than Python 2
and they are incompatible with each other. Six doesn't provide
a transparent wrapper around this, so the most sane thing to do
is to not use octal literals. If you need an octal literal,
use a decimal literal and if it's not obvious what the value is,
provide the value in octal as a comment.
llvm-svn: 251328
The problem was that the @skipIfNoSBHeaders on darwin was trying to use self.lib_dir when it hadn't been set yet.
I looked at the code and places were required to set "self.lib_dir" for no real reason as all places that used it just used the LLDB_LIB_DIR environment variable. So I removed all uses of self.lib_dir and replaced them to use 'os.environ["LLDB_LIB_DIR"]'. Did the same for self.implib_dir.
llvm-svn: 251315
Also since we always read in the DWARF data or mmap it, we don't need to make a copy of the strings for the directories and file names, we can just store "cosnt char *" values. Every place that uses the prologues use them temporarily and then throw them away so no one is expecting the directory and filename strings to live longer than the parse functions.
llvm-svn: 251310
Python3 has no analogue to sys.maxint since ints in Python 3 have
arbitrary size. However, the distinction was not actually important
in any of these cases, and in a few cases using maxint was already
a bug to begin with.
llvm-svn: 251306
This avoids the need to query the PC for private resume operations (public resumes have the PC
from the bigger jStopInfo packet) and speeds up the stepping on an android target by about 10%
(it some cases even more).
llvm-svn: 251301
Adds option -c <x,y,z> to the 'language renderscript kernel breakpoint set' command.
Breaks only on the invocation of the kernel with specified coordinate.
Implemented by adding a callback to the kernel breakpoint which checks the coordinates of every invocation.
llvm-svn: 251293
Summary:
Per discussions on the mailing list, I have implemented a decorator which annotates individual
test methods with categories. I have used this framework to replace the '-a' and '+a'
command-line switches (now '-G pyapi' and '--skip-category pyapi') and the @python_api_test
decorator (now @add_test_categories('pyapi')). The test suite now gives an error message
suggesting the new options if the user specifies the deprecated +/-a switches. If the general
direction is good, I will follow this up with other switches.
Reviewers: tberghammer, tfiala, granata.enrico, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14020
llvm-svn: 251277
This is just a trivial patch that corrects a couple of return value account to function's return type.
Also corrects typo in hardware breakpoint handler.
llvm-svn: 251269
Also added a placeholder Editline gtest for some code that I'll add as soon
as I make sure this addition doesn't break any of the build bots.
This change also introduces some Xcode user-defined variables that I've used
to attempt to isolate the way Python is integrated into the build. I don't have
the rest of LLDB using it yet, I'm using the gtests as my guinea pig on that.
Currently these are:
PYTHON_FRAMEWORK_PATH
PYTHON_VERSION_MAJOR
PYTHON_VERSION_MINOR
I will convert the rest over to it after this gets a little time to bake
and any kinks are worked out of it.
llvm-svn: 251261
I am also letting a debugserver-related project entry slide in
since Xcode seems to insist on inserting it, and when I remove it
the new files don't show up.
llvm-svn: 251243
A variable of type:
struct S {
union {
int i1;
unsigned u1;
};
union {
int i2;
unsigned u2;
};
};
had been impossible to evaluate in lldb-mi, because MI assigns '??' as the
variable name to each of the unnamed unions after "-var-list-children" command.
Also '??' incorrectly goes to 'exp' field which is treated by IDE as a
structure field name and is displayed in watch window.
The patch fixes this returning empty string as type name for unnamed union and
assigning $N to variable name, where N is the field number in the parent entity.
Patch from evgeny.leviant@gmail.com
Reviewed by: clayborg, abidh
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13947
llvm-svn: 251176
This fixes the OSX build for XCode versions older than 7 by skipping
references to LC_VERSION_MIN_TVOS and LC_VERSION_MIN_WATCHOS if
TARGET_OS_TV or TARGET_OS_WATCH aren't defined.
Reviewed by: jasonmolenda
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14036
llvm-svn: 251172
Summary:
These changes aren't everything what is needed for the autotools target, but it's significantly approaching it.
These changes shouldn't effect the build process on other platforms.
Patch by Kamil Rytarowski, thanks!
Reviewers: joerg, brucem
Subscribers: brucem, tberghammer, danalbert, srhines, lldb-commits
Differential Revision: http://reviews.llvm.org/D13715
llvm-svn: 251171
Summary:
These changes aren't everything what is needed for the CMake target, but it's significantly approaching it.
These changes shouldn't effect the build process on other platforms.
Patch by Kamil Rytarowski, thanks!
Reviewers: joerg, brucem
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13711
llvm-svn: 251164
in DWARF as a member of a class, but it has a "this" parameter. Specifically,
*this needs to have the LLDB expression added as a method.
This fixes TestWithLimitDebugInfo.
llvm-svn: 251151
Summary:
"from __future__ import print_function" was added to the test file but
not to the embedded interpreter. This change uses file.write instead to
avoid all problems with print.
Reviewers: zturner
Subscribers: zturner, lldb-commits
Differential Revision: http://reviews.llvm.org/D14029
llvm-svn: 251150
Six provides six.u() which resolves to either u"" or "" depending on
Python version, and and six.unichr() which resolves to either unichr()
or chr() depending on Python version. Use these functions anywhere
where we were relying on u"" or unichr().
llvm-svn: 251139
This is caused by a bug in MSVC's library implementation. It's
fixed in the next version of the compiler, but for now the only
way to silence this is to disable the warning.
llvm-svn: 251130
Apparently there were tons of instances I missed last time, I
guess I accidentally ran 2to3 non-recursively. This should be
every occurrence of a print statement fixed to use a print function
as well as from __future__ import print_function being added to
every file.
After this patch print statements will stop working everywhere in
the test suite, and the print function should be used instead.
llvm-svn: 251121
* Use PTRACE_GETVFPREGS/PTRACE_SETVFPREGS to access the floating point
registers instead of the old PTRACE_GETFPREGS/PTRACE_SETFPREGS. The
new call is available since armv5.
* Work around a kernel issue in PTRACE_POKEUSER with reading out the full
register set, modifying the neccessary value and then writing it back.
llvm-svn: 251111
GCC produce a lot of strict-aliasing warning for the LLDB codebase
what makes reading the compile output very difficult. This change
disable these warnings to reduce the noise as we already ignore them.
We should consider re-enabling the warning if we fix all (or most)
strict-aliasing violation first.
Differential revision: http://reviews.llvm.org/D13981
llvm-svn: 251107
Re-commit the change after fixing a lot of race condition in LLDB
exposed by this change
Loading the debug info from a large application is the slowest task
LLDB do. This CL makes most of the dwarf parsing code multi-threaded.
As a result the speed of "attach; backtrace; exit;" when the inferior
is an LLDB with full debug info increased by a factor of 2.
Differential revision: http://reviews.llvm.org/D13662
llvm-svn: 251106
The Timer class already had some support for multi-threaded access
but it still contained several race conditions. This CL fixes them
in preparation of adding multi-threaded dwarf parsing (and other
multi-threaded parts later).
Differential revision: http://reviews.llvm.org/D13940
llvm-svn: 251105
Summary:
The list of loaded modules which skip_if_library_missing is depending on is not available on
linux until after we run the target. This causes the tests to be wrongfully skipped. This commit
moves the skip call after the run command.
Reviewers: granata.enrico, tfiala
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13985
llvm-svn: 251102
previous release. Most of the diffs are duplication in the xcode
project file caused by adding a "debugserver-mini" target. Jim
Ingham added support for a new SPI needed to request app launches
on iOS. Greg Clayton added code to indicate the platform of the
binary (macosx, ios, watchos, tvos) based on Mach-O load commands.
Jason Molenda added code so debugserver will identify when it is
running on a tvos/watchos device to lldb.
llvm-svn: 251091
Previously, lldb did not use type summaries for simple types with no children
(like function pointers). This patch enables MI to use lldb type summaries for
evaluation of all types of objects, so MI own formatters are no longer needed.
Patch from evgeny.leviant@gmail.com
Reviewed by: abidh
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13799
llvm-svn: 251082
This patch enables type summary for 'char' type. Given:
char c = 'h';
Before this patch, c evaluates as:
(char) $0 = 'h'
After this patch, we get:
(char) $0 = 104 'h'
This change allows the formatting of character types in MI to be removed
and replaced with that in lldb, and can be useful when evaluating
non-printable characters.
Patch from evgeny.leviant@gmail.com
Reviewed by: granata.enrico
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13657
llvm-svn: 251080
Under Python 2 this has no effect, since map() returns a list.
In Python 3 map() returns an iterable, so wrapping in a list is
necessary to keep the same semantics.
llvm-svn: 251060
This is necessary in order to allow third party modules to be
located under lldb/third_party rather than under the test
folder directly.
Since we're already touching every test file anyway, we also
go ahead and delete the unittest2 import and main block wherever
possible. The ability to run a test as a standalone file has
already been broken for some time, and if we decide we want this
back, we should use unittest instead of unittest2.
A few places could not have the import of unittest2 removed,because
they depend on the unittest2.expectedFailure or skip decorators.
Removing all those was orthogonal in spirit to the purpose of this
CL, so the import of unittest2 remains in those files that were
using it for its test decorators. Those can be addressed
separately.
llvm-svn: 251055
Summary:
This short-circuits the GetObjCVersion function to avoid iterating through target modules on
non-apple targets. This function is called on every Process::IsDynamicValue call, so this
overhead is not negligible.
Reviewers: clayborg, jingham
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13948
llvm-svn: 251004
Previously we could not hook the RS runtime on mips64 architectures.
Patch implements ABI specific code for inspecting function arguments.
Author: Dean De Leo, dean@codeplay.com
llvm-svn: 251003
make it easier to run hand-built lldb roots and retain those
entitlements. This is currently only used by Xcode; command
line lldb doesn't expose the SBLaunchInfo::SetUserID()
launch option.
<rdar://problem/23154486>
llvm-svn: 250981
libraries" altogether. On Mac/iOS, these are libraries which have
a UUID and nlist records but no text or data. If one of these
gets into the global module list, every time we try to search
for a given filename/arch/UUID, we'll get this stub library back.
We need to prevent them from getting added to the module list
altogether.
I thought about doing this down in ObjectFileMachO -- just rejecting
the file as a valid binary file altogether -- but Greg didn't want
to take that hard line approach at this point, he wanted to keep
the ability for lldb to read one of these if someone wanted to in
the future.
<rdar://problem/23035075>
llvm-svn: 250979
Before, in the absence of any configured REPLs, LLDB would act as if there were
multiple possible REPL options, whereas actually no REPL language is supported.
Now we make a better error.
llvm-svn: 250931
Summary:
Along with this, support for an optional argument to the "num_children"
method of a Python synthetic child provider has also been added. These have
been added with the following use case in mind:
Synthetic child providers currently have a method "has_children" and
"num_children". While the former is good enough to know if there are
children, it does not give any insight into how many children there are.
Though the latter serves this purpose, calculating the number for children
of a data structure could be an O(N) operation if the data structure has N
children. The new method added in this change provide a middle ground.
One can call GetNumChildren(K) to know if a child exists at an index K
which can be as large as the callers tolerance can be. If the caller wants
to know about children beyond K, it can make an other call with 2K. If the
synthetic child provider maintains state about it counting till K
previosly, then the next call is only an O(K) operation. Infact, all
calls made progressively with steps of K will be O(K) operations.
Reviewers: vharron, clayborg, granata.enrico
Subscribers: labath, lldb-commits
Differential Revision: http://reviews.llvm.org/D13778
llvm-svn: 250930
Summary:
Loop detection code is being called before every element access. Although it tries to cache some
of the data by remembering the loop-free initial segment, every time it needs to increase this
segment, it will start from scratch. For the typical usage pattern, where one accesses the
elements in order, the loop detection will need to be run after every access, resulting in
quadratic behavior. This behavior is noticable even for the default 255 element limit.
In this commit, I rewrite the algorithm to be truly incremental -- it maintains the state of its
loop-detection runners between calls, and reuses them when it needs to check another segment.
This way, each part of the list is scanned only once, resulting in linear behavior.
Also note that I have changed the operator== of ListEntry to do the comparison based on the
value() function (instead of relying on ValueObjectSP equality). In my experiments, I kept
getting different ValueObjectSPs when going through the same element twice.
Reviewers: granata.enrico
Subscribers: lldb-commits, sivachandra
Differential Revision: http://reviews.llvm.org/D13902
llvm-svn: 250890
Patch adds command 'language renderscript allocation save' to store the contents of an allocation in a binary file.
And 'language renderscript allocation load' to restore an allocation with the saved data from a binary file.
Binary file format contains a header FileHeader with meta information preceding the raw data.
Reviewed by: jingham, clayborg
Subscribers: lldb-commits, domipheus
Differential Revision: http://reviews.llvm.org/D13903
llvm-svn: 250886
To allow that, I've added a SetREPL call to the Target, which allows a REPL
that just created a target to install itself as the go-to REPL for the
corresponding language.
llvm-svn: 250870
Right now our Python code does not all share a common root. Tests and
scripts both contain python code that cannot take advantage of reusability
since they are unrelated siblings of each other.
In particular, this presents a problem for wanting to use third party
packages from both sides, since it does not make sense to copy the module
into both places.
This patch solves this by introducing a script lldb_shared.py which is a
very lightweight script that just searches up the tree until it finds a
root, and then imports a module from there. That module knows how to
find all of the shared code that LLDB uses, and adjusts sys.path
accordingly to make them all visible.
llvm-svn: 250858
Six is a python module designed to smooth the process of porting
Python 2 code to Python 3. Specifically, six provides a consistent
interface to some of the breaking changes between 2 and 3. For example,
the syntax for assigning a metaclass differs in Python 2 and 3. Six
addresses this by providing a single class decorator that will do the
right thing depending on which version of Python is being run.
There are other examples too, such as dealing with renamed modules,
unicode literals, etc.
llvm-svn: 250857
Work around a bug in MSVC 12 where _HAS_EXCEPTIONS=0 don't eliminate
all usage of __uncaught_exception with including eh.h what declares
that function.
llvm-svn: 250833
Revert it bacuse it introduces several race condition detected by
the build bots.
This reverts commit 5107a5ebdb7c4571a30a7098b40bf8098b678447.
llvm-svn: 250832
Loading the debug info from a large application is the slowest task
LLDB do. This CL makes most of the dwarf parsing code multi-threaded.
As a result the speed of "attach; backtrace; exit;" when the inferior
is an LLDB with full debug info increased by a factor of 2 (on my machine).
Differential revision: http://reviews.llvm.org/D13662
llvm-svn: 250821
The purpose of the class is to make it easy to execute tasks in parallel
Basic design goals:
* Have a very lightweight and easy to use interface where a list of
lambdas can be executed in parallel
* Use a global thread pool to limit the number of threads used
(std::async don't do it on Linux) and to eliminate the thread creation
overhead
* Destroy the thread currently not in use to avoid the confusion caused
by them during debugging LLDB
Possible future improvements:
* Possibility to cancel already added, but not yet started tasks
* Parallel for_each implementation
* Optimizations in the thread creation destroyation code
Differential revision: http://reviews.llvm.org/D13727
llvm-svn: 250820
Summary:
ADB packets have a maximum size of 4k. This means the size of memory reads does not affect speed
too much (as long as it fits in one packet). Therefore, I am increasing the default memory read
size for android to 2k. This value is used only if the user has not modified the default
memory-cache-line-size setting.
Reviewers: clayborg, tberghammer
Subscribers: tberghammer, danalbert, srhines, lldb-commits
Differential Revision: http://reviews.llvm.org/D13812
llvm-svn: 250814
"expr -r" does this. It also returns to a REPL if the LLDB command interpreter
is neseted inside it, for example in cases where a REPL command resulted in a
breakpoint being hit or a crash.
llvm-svn: 250780
This makes LLDB launch and create a REPL, specifying no target so that the REPL
can create one for itself. Also added the "--repl-language" option, which
specifies the language to use. Plumbed the relevant arguments and errors
through the REPL creation mechanism.
llvm-svn: 250773
m_directory = "/tmp"
m_filename = "."
To look like:
m_directory = "/tmp/."
m_filename = "foo.txt"
if "foo.txt" was appended to it. With this fix it will be:
m_directory = "/tmp"
m_filename = "foo.txt"
llvm-svn: 250770
This patch was generating by running `2to3` on the files in the
lldb/test directory. This patch should be NFC, but it does
introduce the `from __future__ import print_function` line, which
will break future uses of the print statement.
llvm-svn: 250763
A REPL takes over the command line and typically treats input as source code.
REPLs can also do code completion. The REPL class allows its subclasses to
implement the language-specific functionality without having to know about the
IOHandler-specific internals.
Also added a PluginManager-based way of getting to a REPL given a language and
a target.
Also brought in some utility code and expression options that are useful for
REPLs, such as line offsets for expressions, ANSI terminal coloring of errors,
and a few IOHandler convenience functions.
llvm-svn: 250753
In r248047, I attempted to fix a build breakage introduced by using
llvm's regex support from lldb-mi. However, my approach was flawed
when LLVM and lldb are dynamically linked, in which case two copies
of LLVMSupport would end up in memory, causing crashes on lldb start up.
Instead, use LINK_COMPONENTS to make sure lldb-mi has access to the
LLVMSupport symbols without causing duplication in the dynamic library
case.
llvm-svn: 250751
This allows open source MacOSX clients to not have to build debugserver and the current LLDB can find debugserver inside the selected Xcode.app on your system.
<rdar://problem/23167253>
llvm-svn: 250735
Even though these are under examples/, they actually get loaded
when LLDB starts up during initialization of ScriptInterpreterPython.
There's obviously some kind of layering issue here (and comments
in the code even point to that as well), but for now just make them
py3 compatible.
llvm-svn: 250710
Newer versions of CMake include a "smarter" FindLibxml2 package.
In theory this is a good thing, but on Windows it's now smart
enough to find the version that comes with Gnuwin32, which doesn't
appear to be a valid libxml2 distribution. Or at the very least,
LLDB currently uses some header files from libxml2 that are not
part of this distribution.
Nobody on Windows is using any of this functionality right now
anyway, so just disable it.
llvm-svn: 250709
This patch corrects the number of bytes of debug register resources which are written while installing or removing a breakpoint using ptrace interface on arm64 targets.
Differential revision: http://reviews.llvm.org/D12522
llvm-svn: 250700
For o32 applications on mips we were getting segmentation fault while launching lldb-server because of overwritting stack when using elf_gregset_t in DoWriteRegisterValue.
We are now using the GPR_mips_linux buffer in DoWriteRegisterValue as done in DoReadRegisterValue also, which solves the above issue.
llvm-svn: 250696
Python requires that Python.h is included before any std header. Not doing so
results in conflicts with standards macros such as `_XOPEN_SOURCE`. NFC.
llvm-svn: 250673
There were a number of const qualifiers being cast away which caused warnings.
This cluttered the output hiding real errors. Silence them by explicit casting.
NFC.
llvm-svn: 250662
ValueObjectPrinter can now mask out pointer values during a printout; also, it supports helper functions to print declarations in different formats if needed
Practically speaking however, this change is NFC as nothing yet uses it in the codebase
llvm-svn: 250599
Using the Python native C API is non-portable across Python versions,
so this patch changes them to use the `PythonFile` class which hides
the version specific differences behind a single interface.
llvm-svn: 250525
Summary:
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.
Reviewers: clayborg, tberghammer
Subscribers: tberghammer, lldb-commits, danalbert, srhines, emaste
Differential Revision: http://reviews.llvm.org/D13772
llvm-svn: 250502
Previous commit r250281 broke TestDataFormatterSmartArray.py
Resolved in in this patch by adding the new enum eFormatVectorOfFloat16 to FormatManager.
Differential Revision: http://reviews.llvm.org/D13730
llvm-svn: 250499
Summary: r249597 introduced a usage of GetTypeSummary in lldb-mi.
That function used to only be available when python is enabled.
However, there is no reason for that anymore since that is now
dealt with at a different abstraction layer.
Reviewers: ki.stfu, evgeny777, clayborg, granata.enrico
Subscribers: elehcim, brucem, lldb-commits
Differential Revision: http://reviews.llvm.org/D13577
llvm-svn: 250494
Summary: This function reads m_frames, so it needs to lock the
mutex like all other function that access m_frames.
Found using AddressSanitizer.
Reviewers: jingham, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13638
llvm-svn: 250493
a few days now where compiler-rt gets an error when trying
to run its install step (related to not being able to find
an ios version of a dylib), breaking the lldb build. I
don't know if I'm the only one seeing this or if everyone has
been doing the same hack I've been doing - removing the
compiler-rt project from the default checkout.
It's only used for the ASAN test case. So I'm temporarily
checking in my hackaround of not checking out compiler-rt
by default, I'll try to get back and look at what's actually
happening in the compiler-rt install step that is causing
the problems when built as a part of lldb.
llvm-svn: 250487
[LLDB] Fix Clang-tidy misc-use-override warnings in remaining files in include; other minor fixes.
Differential Revision: http://reviews.llvm.org/D13681.
llvm-svn: 250476
It was adding all the test infrastructure paths properly, but it
was not adding the lldb module. The current approach only adds the
lldb from the path. That can be improved (in the comments) to add
the one from the related build directory if it can be ascertained.
With this change, lldb tests can be run through pylint/flake8
and have the lldb module found and used as part of the checks.
llvm-svn: 250453
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
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
Summary:
I see a lot of following warnings in LLDBWrapPython.cpp while building with gcc 4.9 on Linux.
"warning: cast from type ‘const char*’ to type ‘char*’ casts away qualifiers [-Wcast-qual]"
Is it ok to add -Wno-cast-qual for this file in cmake for gcc. This option seems to be already present
for autotool case.
Reviewers: zturner, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13719
llvm-svn: 250380
disabled the use of the jThreadGetExtendedInfo packet which is used
to retrieve additional information about a thread, such as the QoS
setting for that thread on darwin systems.
Re-enable the use of the jThreadGetExtendedInfo packet, and add
some quick tests to the TestQueues mac test case which will verify
that we can retrieve the QoS names for these test threads.
<rdar://problem/22925096>
llvm-svn: 250364
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
There were a couple of issues related to string handling that
needed to be fixed. In particular, we cannot get away with
converting `PyUnicode` objects to `PyBytes` objects and storing
the `PyBytes` regardless of Python version. Instead we have to
store a `PyUnicode` on Python 3 and a `PyString` on Python 2.
The reason for this is that if you call `PyObject_Str` on a
`PyBytes` in Python 3, it will return you a string that actually
contains the string value wrappedin the characters b''. So if we
create a `PythonString` with the value "test", and we call Str()
on it, we will get back the string "b'test'", which breaks string
equality. The only way to fix this is to store a native
`PyUnicode` object under Python 3.
With this CL, ScriptInterpreterPythonTests unit tests pass 100%
under Python 2 and Python 3.
llvm-svn: 250327
Python 3 reverses the order in which you must call Py_InitializeEx
and PyEval_InitThreads. Since that log is in itself already a
little nuanced, it is refactored into a function so that the reversal
is more clear. At the same time, there's a lot of logic during
Python initialization to save off a bunch of state and then restore
it after initialization is complete. To express this more cleanly,
it is refactored to an RAII-style pattern where state is saved off
on acquisition and restored on release.
llvm-svn: 250306
Added a constructor that takes list_size for `PythonList`.
Made all single-argument constructors explicit.
Re-ordered constructors to be consistent with other classes.
llvm-svn: 250304
Adding the following flag to a cmake line:
-DLLDB_EXPORT_ALL_SYMBOLS=TRUE
will cause all symbols to be exported from liblldb. This enables the llvm
backtrace mechanism to see and report backtrace symbols properly when using
(lldb) log enable --stack ...
Prior to this change, only the SB API symbols would show up on Linux and other
systems that use a public-symbols-based backtrace lookup mechanism.
log enable --stack ... is a very handy, quick way to understand the flow
of how some log lines are getting hit within lldb without having to hook
up a top-level debugger over your current debug session.
llvm-svn: 250299
Summary:
This commit adds support for binary memory reads ($x) to lldb-server. It also removes the "0x"
prefix from the $x client packet, to make it more compatible with the old $m packet. This allows
us to use almost the same code for handling both packet types. I have verified that debugserver
correctly handles $x packets even without the leading "0x". I have added a test which verifies
that the stub returns the same memory contents for both kinds of memory reads ($x and $m).
Reviewers: tberghammer, jasonmolenda
Subscribers: iancottrell, lldb-commits
Differential Revision: http://reviews.llvm.org/D13695
llvm-svn: 250295
Previously ConstString had a single mutex guarding the global string
pool for each access what become a bottleneck when using it with a
large number of threads.
This CL distributes the strings to 256 individual string pools based on
a simple hash function to eliminate the bottleneck and speed up the
multi-thread access.
The goal of the change is to prepare to multi-threaded symbol parsing code
to speed up the symbol parsing speed.
Differential revision: http://reviews.llvm.org/D13652
llvm-svn: 250289
It is a new function added to the llvm::Triple class to simplify the
checking if we are targeting android to clean up the confusion between
android being an OS or an environment.
llvm-svn: 250286
This patch adds the command 'language renderscript allocation dump <ID>' for printing the contents of a RS allocation.
Displaying the coordinate of each element as well as its formatted value
e.g (lldb) language renderscript allocation dump 1
Data (X, Y, Z):
(0, 0, 0) = {0 1}
(1, 0, 0) = {2 3}
(2, 0, 0) = {4 5}
A --file <filename> option is also included, since for large allocations it may be more helpful to view this text as a file.
Reviewed by: jingham, clayborg
Subscribers: lldb-commits, ADodds, domipheus, brucem
Differential Revision: http://reviews.llvm.org/D13699
llvm-svn: 250281
* 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
PythonObjects were being incorrectly ref-counted. This problem was
pervasive throughout the codebase, leading to an unknown number of memory
leaks and potentially use-after-free.
The issue stems from the fact that Python native methods can either return
"borrowed" references or "owned" references. For the former category, you
*must* incref it prior to decrefing it. And for the latter category, you
should not incref it before decrefing it. This is mostly an issue when a
Python C API method returns a `PyObject` to you, but it can also happen with
a method accepts a `PyObject`. Notably, this happens in `PyList_SetItem`,
which is documented to "steal" the reference that you give it. So if you
pass something to `PyList_SetItem`, you cannot hold onto it unless you
incref it first. But since this is one of only two exceptions in the
entire API, it's confusing and difficult to remember.
Our `PythonObject` class was indiscriminantely increfing every object it
received, which means that if you passed it an owned reference, you now
have a dangling reference since owned references should not be increfed.
We were doing this in quite a few places.
There was also a fair amount of manual increfing and decrefing prevalent
throughout the codebase, which is easy to get wrong.
This patch solves the problem by making any construction of a
`PythonObject` from a `PyObject` take a flag which indicates whether it is
an owned reference or a borrowed reference. There is no way to construct a
`PythonObject` without this flag, and it does not offer a default value,
forcing the user to make an explicit decision every time.
All manual uses of `PyObject` have been cleaned up throughout the codebase
and replaced with `PythonObject` in order to make RAII the predominant
pattern when dealing with native Python objects.
Differential Revision: http://reviews.llvm.org/D13617
Reviewed By: Greg Clayton
llvm-svn: 250195
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
set to true, but all plans run by RunThreadPlan need to have this set to false so they will
return control to RunThreadPlan without consulting plans higher on the stack.
Since this seems like a common error, I also modified RunThreadPlan to enforce this behavior.
<rdar://problem/22543166>
llvm-svn: 250084
strictly necessary because RunToAddress is always used as a subsidiary plan, so
it's ShouldStop seldom matters. But get it right anyway.
llvm-svn: 250083
Summary:
Test decorators were ignoring AttributeError exceptions. These were introduced three years ago,
and copied to all decorators. They seem to serve no purpose and removing them produces no errors.
Given that they have prevented us from noticing the problem in r249819, I am removing them.
Reviewers: zturner, tfiala
Subscribers: iancottrell, lldb-commits
Differential Revision: http://reviews.llvm.org/D13583
llvm-svn: 250038
* XFAIL it for android arm/aarch64 as watchpoints aren't supported there
* Remove the dwarf/dsym test separation as they will be generated automatically
llvm-svn: 250024
Summary:
- Changed from 16 bits to 8 bits for Intel Architecture
-- FXSAVE structure now conforms with the layout of FXSAVE
area specified by IA Architecture Software Developer Manual
- Modified Linux and FreeBSD specific files to support this change
-- MacOSX already uses 8 bits for ftag register
- Modified TestRegisters.py and a.cpp:
-- Change allows 8 bit comparison of ftag values
-- Change resolves Bug 24733:
Removed XFAIL for Clang as the test works and passes for
Clang compiler as well
-- Change provides a Generic/Better way of testing Bug 24457
and Bug 25050 by using 'int3' inline assembly in inferior
Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com>
Reviewers: ovyalov, jingham, clayborg
Subscribers: tfiala, emaste
Differential Revision: http://reviews.llvm.org/D13587
llvm-svn: 250022
The underlying raw_string_stream buffer was not being flushed
after asking llvm to collect the backtrace. This worked fine
on OS X but was failing to print anything on Linux.
llvm-svn: 249930
Summary:
This is second attempt based on current code.
I checked this patch on my own build on RHEL 6.
Please check it in if it's OK, because I don't have SVN write access.
Patch by Eugene Zelenko.
Reviewers: labath, brucem, clayborg
Subscribers: amccarth, lldb-commits
Differential Revision: http://reviews.llvm.org/D13574
llvm-svn: 249928
Summary: On x86, we only have 4 watchpoint registers.
Reviewers: mohit.bhakkad
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13608
llvm-svn: 249916
With this change, liblldb is 95% of the way towards being able
to work under both Python 2.x and Python 3.x. This should
introduce no functional change for Python 2.x, but for Python
3.x there are some important changes. Primarily, these are:
1) PyString doesn't exist in Python 3. Everything is a PyUnicode.
To account for this, PythonString now stores a PyBytes instead
of a PyString. In Python 2, this is equivalent to a PyUnicode,
and in Python 3, we do a conversion from PyUnicode to PyBytes
and store the PyBytes.
2) PyInt doesn't exist in Python 3. Everything is a PyLong. To
account for this, PythonInteger stores a PyLong instead of a
PyInt. In Python 2.x, this requires doing a conversion to
PyLong when creating a PythonInteger from a PyInt. In 3.x,
there is no PyInt anyway, so we can assume everything is a
PyLong.
3) PyFile_FromFile doesn't exist in Python 3. Instead there is a
PyFile_FromFd. This is not addressed in this patch because it
will require quite a large change to plumb fd's all the way
through the system into the ScriptInterpreter. This is the only
remaining piece of the puzzle to get LLDB supporting Python 3.x.
Being able to run the test suite is not addressed in this patch.
After the extension module can compile and you can enter an embedded
3.x interpreter, the test suite will be addressed in a followup.
llvm-svn: 249886
Instead check what languages are supported for expressions; use C if available,
but otherwise pick one of the supported languages.
This can be overridden using the target settings.
<rdar://problem/22290878>
llvm-svn: 249864
Summary:
Add dependencies to the custom commands so that they get
re-executed as needed.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13580
llvm-svn: 249860
Summary:
EnablePluginLogging, GetPluginCommandHelp and ExecutePluginCommand aren't
implemented or used anywhere, so remove them from the Hexagon and POSIX
Dynamic Loaders as well as the FreeBSD process.
Reviewers: clayborg, labath, emaste
Subscribers: lldb-commits, emaste
Differential Revision: http://reviews.llvm.org/D13581
llvm-svn: 249840
Summary:
Log files produced by dotest have names derived from the test name, and this produces errors in
case we have multiple tests with the same name. Additionally, it's good if the test name explains
what the test is testing (which it clearly doesn't do well if there are multiple tests with
identical names). This commit makes the presence of such tests a hard error.
Reviewers: tberghammer, zturner
Subscribers: iancottrell, lldb-commits
Differential Revision: http://reviews.llvm.org/D13588
llvm-svn: 249828
We want to skip these tests when the target platform is darwin, not
when the host because they have to be enabled in case of darwin ->
android
llvm-svn: 249825
Summary:
This is Darwin only.
The symbol defined by ${LLDB_VERS_GENERATED_FILE} is used by
source/lldb.cpp, so anything that uses lldb.cpp (which is in
lldbBase) should also have the generated symbol. This means
that the entire process can be centralized within source/CMakeLists.txt
where lldbBase is constructed.
Additionally, the custom command should have dependencies on the
project file as well as the generation script so that if either
changes, the version file is correctly re-generated and everything
is re-linked appropriately.
* cmake/LLDBDependencies.cmake: Remove everything related to
the generated version file from here.
* source/CMakeLists.txt: On Darwin, add the generated version
file to the sources that make up lldbBase. Also, create a
custom target and make lldbBase depend on it to re-generate
the generated file as needed.
* source/API/CMakeLists.txt: Don't need to build the generated
version file here or use it to control linking against swig_wrapper.
* tools/lldb-server/CMakeLists.txt: Likewise.
Reviewers: dawn, sas, clayborg, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13552
llvm-svn: 249806
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
This involved changing the TypeSystem::CreateInstance to take a module or a target. This allows type systems to create an AST for modules (no expression support needed) or targets (expression support is needed) and return the correct class instance for both cases.
llvm-svn: 249747
The <no-defaults> special entry will prevent that specific directory's excludes from
receiving the global default source excludes. This allows overriding the global default
in a specific instance, simplifying the syntax for that case.
llvm-svn: 249705
Summary:
In bug 24074, the type information is not shown
correctly. This commit includes the following -
-> Changes for displaying correct type based on
current lexical scope for the command "image
lookup -t"
-> The corresponding testcase.
-> This patch was reverted due to segfaults in
FreeBSD and Mac, I fixed the problems for both now.
Reviewers: emaste, granata.enrico, jingham, clayborg
Differential Revision: http://reviews.llvm.org/D13290
llvm-svn: 249673
Summary:
Previously CMake would display messages like these:
```
-- LLDB Found PythonExecutable: $<$<CONFIG:Debug>:C:/Projects/Python-2.7.9-bin/x64/python_d.exe>$<$<NOT:$<CONFIG:Debug>>:C:/Projects/Python-2.7.9-bin/x64/python.exe>
-- LLDB Found PythonLibs: $<$<CONFIG:Debug>:C:/Projects/Python-2.7.9-bin/x64/libs/python27_d.lib>$<$<NOT:$<CONFIG:Debug>>:C:/Projects/Python-2.7.9-bin/x64/libs/python27.lib>
-- LLDB Found PythonDLL: $<$<CONFIG:Debug>:C:/Projects/Python-2.7.9-bin/x64/python27_d.dll>$<$<NOT:$<CONFIG:Debug>>:C:/Projects/Python-2.7.9-bin/x64/python27.dll>
```
This patch makes the messages look like this:
```
-- LLDB Found PythonExecutable: C:/Projects/Python-2.7.9-bin/x64/python.exe and C:/Projects/Python-2.7.9-bin/x64/python_d.exe
-- LLDB Found PythonLibs: C:/Projects/Python-2.7.9-bin/x64/libs/python27.lib and C:/Projects/Python-2.7.9-bin/x64/libs/python27_d.lib
-- LLDB Found PythonDLL: C:/Projects/Python-2.7.9-bin/x64/python27.dll and C:/Projects/Python-2.7.9-bin/x64/python27_d.dll
```
I've also added checks to ensure the messages are actually accurate, as in check that the files actually exist before claiming they've been found. If any of the files are missing Python integration will be disabled for the build.
Patch by Vadim Macagon. Thanks!
Reviewers: brucem, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13520
llvm-svn: 249671
Summary: This change fixes pr24916. As associated test has been added.
Reviewers: clayborg
Subscribers: zturner, lldb-commits
Differential Revision: http://reviews.llvm.org/D13224
llvm-svn: 249629
When the target settings are consulted to decide the expression language
is decided in CommandObjectExpression, this doesn't help if you're running
SBFrame::EvaluateExpression(). Moving the logic into UserExpression fixes
this.
Based on patch from scallanan@apple.com
Reviewed by: dawn
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13267
llvm-svn: 249624
If a string contained characters outside the ASCII range, lldb-mi would
print them as hexadecimal codes. This patch fixes this behaviour by
converting to UTF-8 instead, by having lldb-mi use registered type
summary providers, when they are available. This patch also fixes
incorrect evaluation of some composite types, like std::string, by
having them use a type registered type summary provider.
Based on patch from evgeny.leviant@gmail.com
Reviewed by: ki.stfu, granata.enrico, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13058
llvm-svn: 249597
Introduce the notion of Language-based formatter prefix/suffix
This is meant for languages that share certain data types but present them in syntatically different ways, such that LLDB can now have language-based awareness of which of the syntax variations it has to present to the user when formatting those values
This is goodness for new languages and interoperability, but is NFC for existing languages. As such, existing tests cover this
llvm-svn: 249587
Summary:
This removes all uses of virtual on functions
where override could be used, including on destructors.
It also adds override where virtual was previously
missing.
Reviewers: clayborg, labath
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13503
llvm-svn: 249564
Summary:
The StackUsesFrames and FunctionCallsChangeCFA virtual functions
aren't used anywhere and aren't overridden by anything.
They were introduced when the ABISysV_ppc* code was added and weren't
used at the time. The review for the commit that added them can be
found at http://reviews.llvm.org/D5988
The commit comment notes that backtraces don't yet work:
Backtraces don't work. This is due to PowerPC ABI using a
backchain pointer in memory, instead of a dedicated frame
pointer register for the backchain.
So there is a possibility these were added with the intent of using
them in the future.
Reviewers: clayborg, jingham, jhibbits, emaste
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13506
llvm-svn: 249563
Enrico Granata