| Age | Commit message (Collapse) | Author |
|---|
|
Summary:
The std::call_once implementation in libstdc++ has problems on few systems: NetBSD, OpenBSD and Linux PPC. LLVM ships with a homegrown implementation llvm::call_once to help on these platforms.
This change is required in the NetBSD LLDB port. std::call_once with libstdc++ results with crashing the debugger.
Sponsored by <The NetBSD Foundation>
Reviewers: labath, joerg, emaste, mehdi_amini, clayborg
Reviewed By: labath, clayborg
Subscribers: #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D29288
llvm-svn: 294202
|
|
Summary:
Per discussion in D28616, having two ways two request logging (log
enable lldb XXX verbose && log enable -v lldb XXX) is confusing. This
removes the first option and standardizes all code to use the second
one.
I've added a LLDB_LOGV macro as a shorthand for if(log &&
log->GetVerbose()) and switched most of the affected log statements to
use that (I've only left a couple of cases that were doing complex
computations in an if(log) block).
Reviewers: jingham, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D29510
llvm-svn: 294113
|
|
Older clangs (<=3.6) complain about a redefinition when we try to specialize a
templace function declared with = delete. Instead, I just don't define the
function body, which will trigger a linker error if someone tries to use an
unknown function.
llvm-svn: 291226
|
|
Also found/fixed one bug identified by this warning in
RenderScriptx86ABIFixups.cpp where a string literal was being used in an
effort to provide a name for an instruction/register, but was instead
being passed as the bool 'isVolatile' parameter.
llvm-svn: 291198
|
|
This is a large API change that removes the two functions from
StreamString that return a std::string& and a const std::string&,
and instead provide one function which returns a StringRef.
Direct access to the underlying buffer violates the concept of
a "stream" which is intended to provide forward only access,
and makes porting to llvm::raw_ostream more difficult in the
future.
Differential Revision: https://reviews.llvm.org/D26698
llvm-svn: 287152
|
|
CommandData breakpoint commands didn't know whether they were
Python or Command line commands, so they couldn't serialize &
deserialize themselves properly. Fix that.
I also changed the "breakpoint list" command to note in the output
when the commands are Python commands. Fortunately only one test
was relying on this explicit bit of text output.
llvm-svn: 282432
|
|
Plumb unique_ptrs<> all the way through the baton interface.
NFC, this is a minor improvement to remove the possibility of an
accidental pointer ownership issue.
Reviewed By: jingham
Differential Revision: https://reviews.llvm.org/D24495
llvm-svn: 281360
|
|
Still to come:
1) SB API's
2) Testcases
3) Loose ends:
a) serialize Thread options
b) serialize Exception resolvers
4) "break list --file" should list breakpoints contained in a file and
"break read -f 1 3 5" should then read in only those breakpoints.
<rdar://problem/12611863>
llvm-svn: 281273
|
|
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:
Firstly, merging this particular commit into a downstream fork may be a huge
effort. Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit. The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):
find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;
The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.
Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit. There are alternatives available that will attempt
to look through this change and find the appropriate prior commit. YMMV.
llvm-svn: 280751
|
|
declaring that it must be first. Failure to do so results in build failures
on macOS due to subtle header conflicts.
llvm-svn: 279315
|
|
It's always hard to remember when to include this file, and
when you do include it it's hard to remember what preprocessor
check it needs to be behind, and then you further have to remember
whether it's windows.h or win32.h which you need to include.
This patch changes the name to PosixApi.h, which is more appropriately
named, and makes it independent of any preprocessor setting.
There's still the issue of people not knowing when to include this,
because there's not a well-defined set of things it exposes other
than "whatever is missing on Windows", but at least this should
make it less painful to fix when problems arise.
This patch depends on LLVM revision r278170.
llvm-svn: 278177
|
|
llvm-svn: 277879
|
|
call.
<rdar://problem/24489419>
llvm-svn: 269686
|
|
typename for display
llvm-svn: 268208
|
|
This time it should also pass the gtests
llvm-svn: 266103
|
|
was lost as part of the SystemLifetimeManager work"
This change breaks python unit tests.
This reverts commit 266033.
llvm-svn: 266050
|
|
as part of the SystemLifetimeManager work
llvm-svn: 266033
|
|
are properly escaped in Python.
The Python import works by ensuring the directory of the module or package is in sys.path, and then it does a Python `import foo`. The original code was not escaping the backslashes in the directory path, so this wasn't working.
Differential Revision: http://reviews.llvm.org/D18873
llvm-svn: 265738
|
|
IOHandler's files instead of always using stdin/out/err.
Removed lldb_private::File::Duplicate() and the copy constructor and the assignment operator that used to duplicate the file handles and made them private so no one uses them. Previously the lldb_private::File::Duplicate() function duplicated files that used file descriptors, (int) but not file streams (FILE *), so the lldb_private::File::Duplicate() function only worked some of the time. No one else excep thee ScriptInterpreterPython was using these functions, so that aren't needed nor desired. Previously every time you would drop into the python interpreter we would duplicate files, and now we avoid this file churn.
<rdar://problem/24877720>
llvm-svn: 263161
|
|
causes LLDB to crash
This is because PyThreadState_Get() assumes a non-NULL thread state and crashes otherwise; but PyThreadState_GET is just a shortcut (in non-Python-debugging builds) for the global variable that holds the thread state
The behavior of CTRL+C is slightly more erratic than one would like. CTRL+C in the middle of execution of Python code will cause that execution to be interrupted (e.g. time.sleep(1000)), but a CTRL+C at the prompt will just cause a KeyboardInterrupt and not exit the interpreter - worse, it will only trigger the exception once one presses ENTER.
None of this is optimal, of course, but I don't have a lot of time to appease the Python deities with the proper spells right now, and fixing the crasher is already a good thing in and of itself
llvm-svn: 260199
|
|
The Visual Studio 2015 build was failing with the following error:
error C2440: 'initializing': cannot convert from 'const char [12]' to 'char *'
This should fix the problem by initializing a non const char array, instead of taking a pointer to const static data.
llvm-svn: 259042
|
|
* lldb::tid_t was being converted incorrectly, so this is updated to use
PythonInteger instead of manual Python Native API calls.
* OSPlugin_RegisterContextData was assuming that the result of
get_register_data was a string, when in fact it is a bytes. So this
method is updated to use PythonBytes to do the work.
llvm-svn: 257398
|
|
Differential Revision: http://reviews.llvm.org/D15209
Reviewed By: Todd Fiala
llvm-svn: 254791
|
|
This is a helper class which supports a number of
features including exception to string formatting with
backtrace handling and auto-restore of exception state
upon scope exit.
Additionally, unit tests are included to verify the
feature set of the class.
llvm-svn: 252994
|
|
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
|
|
llvm-svn: 250838
|
|
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
|
|
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
|
|
llvm-svn: 250322
|
|
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
|
|
llvm-svn: 250303
|
|
llvm-svn: 250282
|
|
llvm-svn: 250213
|
|
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
|
|
llvm-svn: 249900
|
|
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
|
|
Previously embedded interpreters were handled as ad-hoc source
files compiled into source/Interpreter. This made it hard to
disable a specific interpreter, or to add support for other
interpreters and allow the developer to choose which interpreter(s)
were enabled for a particular build.
This patch converts script interpreters over to a plugin-based system.
Script interpreters now live in source/Plugins/ScriptInterpreter, and
the canonical LLDB interpreter, ScriptInterpreterPython, is moved there
as well.
Any new code interfacing with the Python C API must live in this location
from here on out. Additionally, generic code should never need to
reference or make assumptions about the presence of a specific interpreter
going forward.
Differential Revision: http://reviews.llvm.org/D11431
Reviewed By: Greg Clayton
llvm-svn: 243681
|
