Summary:
LLGS leaks pipes (when launched by lldb), sockets (when launched by platform),
and/or log file to the inferior. This should prevent all possible leaks.
Reviewers: vharron, clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9211
llvm-svn: 235615
Summary:
Currently if two instances of lldb-mi are running with logging enabled using '--log' the log file conflicts. This produces the following error
MI: Error: File Handler. Error Permission denied opening 'C:\Users\Ewan\LLVM\build\Debug\bin\lldb-mi-log.txt'
Fixed in this patch by renaming lldb-mi-log.txt based on the date, e.g. lldb-mi-log.txt-20150316163631.log, and moving the file into the temp directory by using the --log-dir option.
Regrading previous review comments the P_tmpdir macro is defined in Windows but always points to "\", which doesn't help much. Also when using the Windows API for GetTempPath() dynamic memory seems much more messy.
Patch from ewan@codeplay.com
Reviewers: abidh, EwanCrawford
Subscribers: zturner, lldb-commits, deepak2427
Differential Revision: http://reviews.llvm.org/D9054
llvm-svn: 235589
Write the new cpsr value into the cpsr register if the BL or the BLX
instruction change the instruction set on arm.
Differential revision: http://reviews.llvm.org/D9188
llvm-svn: 235585
The test case lookinhg for the abort function in the stack trace.
Previously it lookd for a function which ends with "abort" but on some
system there are multiple such functions (e.g.: on android abort calls
__libc_android_abort) what made the test fail. This CL change the
behaviour to look for the abort function based on a fix list of names.
llvm-svn: 235584
The following situation occured if we were stopping a process (due to breakpoint, watchpoint, ...
hit) while a new thread was being created.
- process has two threads: A and B.
- thread A hits a breakpoint: we send a STOP signal to thread B and register a callback with
ThreadStateCoordinator to send a stop notification after the thread stops.
- thread B stops, but not due to the SIGSTOP, but on a thread creation event (of a new thread C).
We are unaware of our desire to stop, so we queue ThreadStopped and RequestResume operations
with TSC, so the thread can continue running.
- TSC receives the ThreadStopped event, sees that all threads are stopped and fires the delayed
stop notification.
- immediately after that TSC gets the RequestResume operation, so it resumes the thread.
At this point the state is inconsistent because LLDB thinks the process is stopped and will start
issuing commands to it, but one of the threads is in fact running. Things eventually break.
I address this problem by omitting the two TSC events altogether and Resuming the thread B
directly. This way the short stop is invisible to the TSC and the delayed notification will not
fire. We will fire the notification when we actually process the SIGSTOP on thread B.
When we get the initial SIGSTOP for thread C, we also resume the thread and send a
ThreadWasCreated message (is_stopped = false) to the TSC. This way, the TSC can stop the thread
on its own and handle the stop event later. This way the state of the new thread is correctly
handled as well (thanks Chaoren for the idea).
This patch also removes the synchronisation between the thread creation notifications on threads
B and C. The need for this synchronisation is unclear (the comments seem to hint that the new
thread is "fully created" only after we process both events, but I have noticed no regressions in
treating it as "created" even after just processing the initial C event), but it is a source for
many kinds of obscure races, since it introduces a new thread state "Launching" and the rest of
the code does not handle this state at all (what happens if we get a resume request from LLDB
while this thread is launching? what happens if we get a stop request? etc.).
This fixes the "spurious $O packet" problem in TestPrintStackTraces.py. However, the test remains
disabled on i386 due to the VDSO issue.
Test Plan:
TestPrintStackTraces works on x86_64. No regressions in the rest of the test suite.
Reviewers: vharron, chaoren
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9145
llvm-svn: 235579
Patch by Jaydeep Patil
Added MIPS32 and MIPS64 core revisions. This would be followed by register context and emulate-instruction for MIPS32.
DYLDRendezvous.cpp:
On Linux link map struct does not contain extra load offset field.
Reviewers: clayborg
Subscribers: bhushan, mohit.bhakkad, sagar, lldb-commits.
Differential Revision: http://reviews.llvm.org/D9190
llvm-svn: 235574
Previously we would pass an argument to finishSwigWrapperClasses.py which
specified whether this was a debug or a release build. But sometimes
CMAKE_BUILD_TYPE would not be set to anything, causing this argument
to be empty when passed in. The only purpose of this argument was to
determine whether or not to append _d to the extension module when
creating the symlink. This is only necessary when doing a debug
build of LLDB on Windows, which implies a debug interpreter, so we
replace this with a check to see if the running interpreter is a debug
one, and append _d if so.
llvm-svn: 235559
breakpoints, for instance on the class of the thrown object.
This change doesn't actually make that work, the part where we
extract the thrown object type from the throw site isn't done yet.
This provides a general programmatic "precondition" that you can add
to breakpoints to give them the ability to do filtering on the LLDB
side before we pass the stop on to the user-provided conditions &
callbacks.
llvm-svn: 235538
Summary:
My understanding of the Windows API call GetLastError() is that it should only be checked when ::GetModuleFileName() returns 0 on error.
Otherwise GetExecutablesPath() could return an error despite nLen being valid if GetLastError() was inconsistent.
Patch updates function to only call GetOSLastError() when nLen == 0
Patch from ewan@codeplay.com
Reviewers: EwanCrawford
Subscribers: lldb-commits, deepak2427
Differential Revision: http://reviews.llvm.org/D9154
llvm-svn: 235515
apparently, TestConcurrentEvents is still not fixed. One test has failed on Linux i386 build.
Will disable the failing test on i386 for now, and see how it goes..
llvm-svn: 235504
After the latest changes in NativeProcessLinux, these tests should be stable now. Please revert
(and let me know) if any issue crops up.
llvm-svn: 235502
On linux-arm we use software single stepping where setting the new
breakpoint is only possible while the process is in stopped state.
This CL moves the setup code for single stepping form the SigneStep
operation into the Resum method to avoid an error when the process
already started when we want to step one of the thread.
Differential revision: http://reviews.llvm.org/D9108
llvm-svn: 235494
Summary: Just what it says on the box.
Reviewers: jasonmolenda
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9150
llvm-svn: 235493
Summary:
- add decorator functions to xfail and skip test on specific os, architecture and version of comipler
- xfail failing test with gcc-4.9.2 on linux
- add one usage of skipIf function
Test Plan:
Run tests with different archs, and version of compilers to verify decorator function working as expected
Run tests with gcc-4.9.2 and no failure reported
Reviewers: sivachandra, ovyalov, vharron, chaoren
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8851
llvm-svn: 235368
-Makefile was deleted by r235313 causing test failure of TestTypedefArray.py, add it back
Summary: -Makefile was deleted by r235313 causing test failure of TestTypedefArray.py, add it back
Test Plan: Run lldb test locally with change, TestTypedefArray.py passed and no regression observed.
Reviewers: chaoren, sivachandra, vharron
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9119
llvm-svn: 235346
ConnectionFileDescriptor::BytesAvailable was reading multiple command
bytes from the command pipe but only processing the first. This
change only allows one byte to be read at a time, ensuring that all
get handled.
This isn't known to cause any bugs, but it might cause current/future
bugs.
Differential Revision: http://reviews.llvm.org/D9098
llvm-svn: 235322
CROSS_COMPILE environment variable is a common convention to specify the path
and/or prefix to cross compilation tools (e.g. ar, objcopy).
Test Plan:
dotest.py $DOTEST_OPTS -t -p 'TestBSDArchives.py|TestBreakpointCommandsFromPython.py|TestFormats.py|TestObjCDynamicValue.py'
All of these tests now compile successfully and pass running macosx -> linux
using a cross compilation toolchain prefixed by CROSS_COMPILE without requiring
changing your PATH. They still pass when run locally on macosx.
Differential Revision: http://reviews.llvm.org/D9072
llvm-svn: 235320
module-loading support for the expression parser.
- It adds support for auto-loading modules referred
to by a compile unit. These references are
currently in the form of empty translation units.
This functionality is gated by the setting
target.auto-import-clang-modules (boolean) = false
- It improves and corrects support for loading
macros from modules, currently by textually
pasting all #defines into the user's expression.
The improvements center around including only those
modules that are relevant to the current context -
hand-loaded modules and the modules that are imported
from the current compile unit.
- It adds an "opt-in" mechanism for all of this
functionality. Modules have to be explicitly
imported (via @import) or auto-loaded (by enabling
the above setting) to enable any of this
functionality.
It also adds support to the compile unit and symbol
file code to deal with empty translation units that
indicate module imports, and plumbs this through to
the CompileUnit interface.
Finally, it makes the following changes to the test
suite:
- It adds a testcase that verifies that modules are
automatically loaded when the appropriate setting
is enabled (lang/objc/modules-auto-import); and
- It modifies lanb/objc/modules-incomplete to test
the case where a module #undefs something that is
#defined in another module.
<rdar://problem/20299554>
llvm-svn: 235313
Summary:
This commit moves the functionality of the operation thread into the new monitor thread. This is
required to avoid a kernel race between the two threads and I believe it actually makes the code
cleaner.
Test Plan: Ran the test suite a couple of times, no regressions.
Reviewers: ovyalov, tberghammer, vharron
Subscribers: tberghammer, lldb-commits
Differential Revision: http://reviews.llvm.org/D9080
llvm-svn: 235304
The arm instruction emulation handles only some of the opcode (including
all of them modifying the PC). For the rest of the instructions we can
advance the PC by the size of the instruction as they don't modify the
PC on any other way.
Differential revision: http://reviews.llvm.org/D9076
llvm-svn: 235292
Previously the read thread was only stopped if CloseOnEOF was set on the
communication channel. It caused it to spin in case of an EOF because
::select() always reported that we can read from the file descriptor.
This CL change this behavior with stopping the read thread on EOF but do
a disconnect only if CloseOnEOF is enabled.
Differential revision: http://reviews.llvm.org/D9077
llvm-svn: 235291
Summary: Caused a failure because it showed up as `__printf`.
Reviewers: ki.stfu
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9060
llvm-svn: 235214
Summary:
This command is currently processed using expression evaluation, meaning the variable binds to the result of the expression not the register.
Therefore any subsequent calls to '-var-assign' will not update the register. Fixed by detecting '$' prefix for registers according to specification.
Thanks, Ewan
Patch from ewan@codeplay.com
Reviewers: EwanCrawford
Subscribers: lldb-commits, deepak2427
Differential Revision: http://reviews.llvm.org/D8965
llvm-svn: 235195
Summary:
This is the first phase of the merging of Monitor and Operation threads in NativeProcessLinux
(which is necessary since the two threads race inside Linux kernel). Here, I reimplement the
Monitor thread do use non-blocking waitpid calls, which enables later addition of code from the
operation thread.
Test Plan: Ran the test suite a couple of times, no regressions detected.
Reviewers: vharron, ovyalov, tberghammer
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9048
llvm-svn: 235193
The debug info section contains some $d mapping symbol what is
overlapping with code sections in other sections of the object file
causing problem in the address class detection. This CL ignores these
symboles from the address class map as the debug info sections don't use
this map.
Differential revision: http://reviews.llvm.org/D9050
llvm-svn: 235171
Uses the target platform to determine the platform context to use. This fixes an
early failure in some tests when running on a different remote target.
Test Plan:
./dotest.py $DOTEST_OPTS -t -p TestGlobalVariables.py|TestSharedLib.py
Running on macosx -> linux, this fails at a later stage in the test - rather
than in registerSharedLibrariesWithTarget looking for a library without the
correct "lib" prefix and ".so" suffix.
Differential Revision: http://reviews.llvm.org/D9047
llvm-svn: 235164
the changes in r233255/r233258. Normally if lldb attaches to
a running process, when we call Process::Destroy, we want to detach
from the process. If lldb launched the process itself, ::Destroy
should kill it.
However, if we attach to a process and the driver calls SBProcess::Kill()
(which calls Destroy), we need to kill it even if we didn't launch it
originally.
The force_kill param allows for the SBProcess::Kill method to force the
behavior of Destroy.
<rdar://problem/20424439>
llvm-svn: 235158
Also add "#if defined( LIBXML2_DEFINED )" around code that already used libxml2 in SymbolVendorMacOSX.cpp.
Cleaned up some warnings in ProcessGDBRemote.cpp.
llvm-svn: 235144
Chaoren Lin