This patch adds functionality for dumping allocations of struct elements. This involves:
+ Jitting the runtime for details on all the struct fields.
+ Finding the name of the struct type by looking for a global variable of the same type, which will have been reflected back to the java host code.
+ Using this struct type name to pass into expression evaluation for pretty printing the data for the dump command.
llvm-svn: 254294
Summary:
This makes sure we do not attempt to send output over the gdb-remote protocol when the client is
not expecting it (i.e., after sending the stop-reply packet). Normally, this should not happen
(the process cannot generate output when it is stopped), but due to the fact that pty
communication is asynchronous in the linux kernel (llvm.org/pr25652), we may sometimes get this
output too late. Instead, we just hold the output, and send it next time we resume. This is not
ideal, but at least it makes sure we do not violate the remote protocol. Given that this happens
extremely rarely it's not worth trying to work around it with sleeps or something like that.
I also remove the m_stdio_communication_mutex, as all of LLGS is now single-threaded anyway.
Reviewers: tberghammer, ovyalov
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D15019
llvm-svn: 254200
correct OS type when running on an apple tv or apple watch.
Also, in TargetList::CreateTargetInternal, check that a platform
is returned by GetPlatformForArchitecture fallback instead of
adding it to the vector of platforms unconditionally; we can end up
crashing when we call a member function on it later.
<rdar://problem/23601982>, <rdar://problem/21292886>
llvm-svn: 253763
Summary:
This reverts commit 2354cd73101e58540b8b39783df462d06023309f as it
introduced a bunch regressions on the linux bot.
Reviewers: emaste, krytarowski
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14844
llvm-svn: 253615
Revert "Remove a few vestigial typedefs from the old world"
This reverts commit 05872cda2a00fbd988c4fc761b1f87fe9edce224.
Revert "Cleanup the type X list commands to use the new ForEach goodness"
This reverts commit 85b1d83819a22cdc9ef12f58fd4fa92b473a4f81.
llvm-svn: 253455
breakpoint as "file address" so that the address breakpoint will track that
module even if it gets loaded in a different place. Also fixed the Address
breakpoint resolver so that it handles this tracking correctly.
llvm-svn: 253308
Python 3 has lots of new debug asserts, and some of these were
firing on PythonFile. Specifically related to handling of invalid
files.
llvm-svn: 253261
This is a first pass at a cleanup of that code, modernizing the "type X clear" commands, and providing the basic infrastructure I plan to use all over
More cleanup will come over the next few days
llvm-svn: 253125
Change Test-rdar-12481949.py to expect GetValueAsUnsigned() to return
0xffffffff if the variable is an int32_t (signed, 4 byte integer) with
value of -1. The previous expectation where we expected the value to be
0xffffffffffffffff doesn't make sense as nothing explains why we would
treat it as an 8 byte value.
This CL also removes a hack from Scalar::ULongLong what was most likely
added to get this test passing as it only worked in case the value of
the variable is -1 and didn't make any sense even in that case.
Differential revision: http://reviews.llvm.org/D14611
llvm-svn: 253027
Summary:
- Reason of both bugs:
1. For the very first frame, Unwinder doesn't check the validity
of Full UnwindPlan before creating StackFrame from it:
When 'process launch' command is run after setting a breakpoint
in inferior, the Unwinder runs and saves only Frame 0 (the frame
in which breakpoint was set) in thread's StackFrameList i.e.
m_curr_frames_sp. However, it doesn't check the validity of the
Full UnwindPlan for this frame by unwinding 2 more frames further.
2. Unwinder doesn't update the CFA value of Cursor when Full UnwindPlan
fails and FallBack UnwindPlan succeeds in providing valid CFA values
for frames:
Sometimes during unwinding of stack frames, the Full UnwindPlan
inside the RegisterContextLLDB object may fail to provide valid
CFA values for these frames. Then the Fallback UnwindPlan is used
to unwind the frames.
If the Fallback UnwindPlan succeeds, then it provides a valid new
CFA value. The RegisterContextLLDB::m_cfa field of Cursor object
is updated during the Fallback UnwindPlan execution. However,
UnwindLLDB misses the implementation to update the 'cfa' field
of this Cursor with this valid new CFA value.
- This patch fixes both these issues.
- Remove XFAIL in test files corresponding to these 2 Bugs
Change-Id: I932ea407545ceee2d628f946ecc61a4806d4cc86
Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com>
Reviewers: jingham, lldb-commits, jasonmolenda
Subscribers: lldb-commits, ovyalov, tberghammer
Differential Revision: http://reviews.llvm.org/D14226
llvm-svn: 253026
correctly handle stepping over one breakpoint directly onto another breakpoint.
This isn't fixing that bug, but rather just changing 252963 to not use breakpoints
if it is only stepping one instruction.
llvm-svn: 253008
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
of addresses, and the range has no branches, instead of running to the last instruction and
single-stepping over that, run to the first instruction after the end of the range. If there
are no branches in the current range, then the bytes right after it have to be in the current
function, and have to be instructions not data in code, so this is safe. And it cuts down one
extra stepi per source range step.
Incidentally, this also works around a bug in the llvm Intel assembler where it treats the "rep"
prefix as a separate instruction from the repeated instruction. If that were at the end of a
line range, then we would put a trap in place of the repeated instruction, which is undefined
behavior. Current processors just ignore the repetition in this case, which changes program behavior.
Since there would never be a line range break after the rep prefix, always doing the range stepping
to the beginning of the new range avoids this problem.
<rdar://problem/23461686>
llvm-svn: 252963
