This finishes the effort to port python-wrapper.swig code over to
using PythonDataObjects.
Also included in this patch is the removal of `PyCallable` from
`python-wrapper.swig`, as it is no longer used after having been
replaced by `PythonCallable` everywhere.
There might be additional cleanup as followup patches, but it should
be all fairly simple and minor.
llvm-svn: 252939
PyCallable is a class that exists solely within the swig wrapper
code. PythonCallable is a more generic implementation of the same
idea that can be used by any Python-related interop code, and lives
in PythonDataObjects.h
The CL is mostly mechanical, and it doesn't cover every possible
user of PyCallable, because I want to minimize the impact of this
change (as well as making it easier to figure out what went wrong
in case this causes a failure). I plan to finish up the rest of
the changes in a subsequent patch, culminating in the removal of
PyCallable entirely.
llvm-svn: 252906
A very expected layout: source tree is in ~/src/llvm, the build directory is in
~/src/llvm-build, and the install location is in /usr/local/{lib,include}.
The DWARF information in /usr/local/lib/libLLVM.a for ilist.h points to
~/src/llvm-build/include/llvm/ADT/ilist.h. Now, when someone includes
"llvm/ADT/ilist.h" and links against /usr/local/lib/libLLVM.a. Disaster.
The DWARF information in libUser.so for ilist.h points to two locations: the one
in /usr/include, and the one in ~/src/llvm-build/include. LLDB gets confused.
Let's uniquify fully-qualified names and never trip on such a thing.
Differential Revision: http://reviews.llvm.org/D14549
llvm-svn: 252898
This had been relegated to a simple forwarding function, so just
delete it in preparation of migrating all of these functions out
of python-wrapper.swig.
llvm-svn: 252803
This only begins to port python-wrapper.swig over. Since this
code can be pretty hairy, I plan to do this incrementally over a
series of patches, each time removing or converting more code
over to the PythonDataObjects code.
llvm-svn: 252788
This adds PythonTuple and PythonCallable classes to PythonDataObjects.
Additionally, unit tests are provided that exercise this functionality,
including invoking manipulating and checking for validity of tuples,
and invoking and checking for validity of callables using a variety
of different syntaxes.
The goal here is to eventually replace the code in python-wrapper.swig
that directly uses the Python C API to deal with callables and name
resolution with this code that can be more easily tested and debugged.
llvm-svn: 252787
This test fails most of the time when run under heavy load. The dsym
variant doesn't seem to be failing.
Tracking XFAIL marker with:
https://llvm.org/bugs/show_bug.cgi?id=25485
llvm-svn: 252702
It used to be a unique pointer, and there could be a case where ClangASTSource
held onto a copy of the pointer but Target::Destroy destroyed the unique pointer
in the mean time.
I also ensured that there is a validity check on the target (which confirms that
a ClangASTImporter can be generated) before the target's shared pointer is
copied into ClangASTSource.
This race condition caused a crash if Target::Destroy was called and then later
the target objecct was deleted.
llvm-svn: 252665
This latter determination may or may not be possible on a per-language basis; and neither is mandatory to implement for any language
Use this knowledge in the ValueObjectPrinter to generalize the notion of IsObjCNil() and the respective printout
llvm-svn: 252663
Fixed a crash that would happen if you tried to get the name of a constructor or destructor by calling "getDeclName()" instead of calling getName() (which would assert and crash).
Added the ability to get function arguments names from SBFunction.
llvm-svn: 252622
"Modify internal breakpoints so they resolve just like external
breakpoints do. This allow you to set symbol and file + line internal
breakpoints and have them get updated correctly."
<rdar://problem/16931767>
llvm-svn: 252584
triple for a process. He writes, "Changes to the way setting the
triple works on a target so that if the target has passed a fully
specified triple, and the newly passed triple is not a revamp of
the current one, and the current one is fully specified, then do
not replace the existing triple."
Triple handling got a bit more complicated on mac with the addition
of ios/watchos/tvos and their simulators, and tracking the correct
os versions for them so expressions are compiled with the expected
APIs available to the user.
<rdar://problem/19820698>
llvm-svn: 252583
Also, add an async error message if the dyld solib loaded callback function
can't find an ABI (which results in no solibs being loaded in the process).
This is a big error and we should call attention to it.
<rdar://problem/23471384>
llvm-svn: 252581
Relying on manual Python C API calls is error prone, especially
when trying to maintain compatibility with Python 2 and Python 3.
This patch additionally fixes what appears to be a potentially
serious memory leak, in that were were incref'ing two values
returned from the session dictionary but never decref'ing them.
There was a comment indicating that it was intentional, but the
reasoning was, I believe, faulty and it resulted in a legitimate
memory leak.
Switching everything to PythonObject based classes solves both
the compatibility issues as well as the resource leak issues.
llvm-svn: 252536
They get treated as special RLE encoding symbols and packets get
corrupted. Most other packet types already know about this apparently,
but QEnvironment missed these two.
Should fix PR25300.
llvm-svn: 252521
In this way, when a language needs to tell itself things that are not bound to a type but to a value (imagine a base-class relation, this is not about the type, but about the ValueObject), it can do so in a clean and general fashion
The interpretation of the values of the flags is, of course, up to the language that owns the value (the value object's runtime language, that is)
llvm-svn: 252503
Summary:
These changes are still incomplete, but we are almost there.
Changes:
- CMake and gmake code
- SWIG code
- minor code additions
Reviewers: emaste, joerg
Subscribers: youri, akat1, brucem, lldb-commits, joerg
Differential Revision: http://reviews.llvm.org/D14042
llvm-svn: 252403
Summary:
Since this is within the lldb namespace, the compiler tries to
export a symbol for it. Unfortunately, since it is inlined, the
symbol is hidden and this results in a mess of warnings when
building on OS X with cmake.
Moving it to the lldb_private namespace eliminates that problem.
Reviewers: clayborg
Subscribers: emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D14417
llvm-svn: 252396
Summary:
On Linux, if a thread-specific conditional breakpoint was hit, it
won't necessarily be the thread that hit the breakpoint itself that
evaluates the conditional expression, so the thread that hit the
breakpoint could still be asked to stop, even though it hasn't been
allowed to run since the previous stop.
Reviewers: sivachandra, jingham
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14472
llvm-svn: 252391
For language that support such a thing, this API allows to ask whether a type is anonymous (i.e. has been given no name)
Comes with test case
llvm-svn: 252390
Python has a complicated mechanism of checking an objects truthity.
This involves a number of steps, which end with calling two private
methods on an object (if they are implemented). In Python 2 these
two methods are `__nonzero__` and `__len__`, and in Python 3 they
are `__bool__` and `__len__`. Because we *also* define a __len__
method for certain iterable types, this was triggering a situation
in Python 3 where `__nonzero__` wasn't defined, so it was calling
`__len__`, which was returning 0 (for example an SBDebugger with
no targets), and as a result the truthosity was determined to be
False.
We fix this by correctly using ` __bool__` for Python 3, and leave
the behavior under Python 2 unchanged.
Note that this fix is only implemented in the SWIG generation
python script, and not the SWIG generation shell script. Someone
more familiar than me with shell scripts will need to fix them
to support this for Python 3 if desired.
llvm-svn: 252382
This is unsupported in Python 3. This could also have been fixed
by using "wb" instead of "w", but it doesn't seem like writing the
session log absolutely *needs* to be unbuffered.
llvm-svn: 252381
instance:
break set -l c++ -r Name
will only break on C++ symbols that match Name, not ObjC or plain C symbols. This also works
for "break set -n" and there are SB API's to pass this as well.
llvm-svn: 252356
`sets.Set` has been deprecated in favor of `set` since 2.6, and
`string.maketrans` has to be special cased. In Python 3 there
is `str.maketrans`, `bytes.maketrans`, and `bytearray.maketrans`
and you have to choose the correct one. So we need to introduce
a runtime version check at this site.
llvm-svn: 252348
Explanation from a Python wizard (not me) about why this exhibited
different behavior under Python 2 and Python 3.
`cmp` is a builtin_function_or_method in Python 2.7, which doesn't
have a __get__ and doesn't qualify as a "descriptor". Your lambda is a
regular function which qualifies as a descriptor whose __get__ method
returns a bound instance.
His suggested fix was to write
sortTestMethodsUsing = staticmethod(cmp_)
However, I don't think `sortTestMethodsUsing` (or any of the other fields
of `TestLoader`) should be class attributes anyway. They are all accessed
through self, so they should be instance attributes. So the fix employed
here is to convert them to instance attributes.
Differential Revision: http://reviews.llvm.org/D14453
Reviewed By: Todd Fiala
llvm-svn: 252346
Summary:
Code that tried to find swig and then split the path into
a separate path and filename is being removed. The invoking
build system always provides the location of swig and we
don't need to split it into 2 pieces only to recombine it
a short time later.
Reviewers: zturner, domipheus
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14415
llvm-svn: 252330
We tried implementing something akin to a conditionalExpectedFailure
decorator for unittest2. We did this by making use of some
implementation details of the unittest2 module. In an effort to make
this work with unittest, this patch removes the reliance on the
implementation details. I have a hard time wrapping my head around
how this all works with the deeply nested decorators, but the spirit
of the patch here is to do do the following: If the condition function
is true, use the original unittest2.expectedFailure decorator. Otherwise
don't use any decorator, just call the test function.
Differential Revision: http://reviews.llvm.org/D14406
Reviewed By: tberghammer, labath
llvm-svn: 252326
We still see "Too many file handles" errors on Windows even with
lower numbers of cores. It's not clear what the right balance is,
and the bar seems to move as more tests get added. So just use
the strategy that works until we can investigate more deeply.
llvm-svn: 252325
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
Adrian McCarthy