Bug 30863 - Step doesn't stop with coditional breakpoint on the next line
Fixed by additional completed plans detection, and applying them on breakpoint condition fail.
Thread::GetStopInfo reworked.

Bug 30863 - Step doesn't stop with coditional breakpoint on the next line
Fixed by additional completed plans detection, and applying them on breakpoint condition fail.
Thread::GetStopInfo reworked. New test added.
Review https://reviews.llvm.org/D26497
Many thanks to Jim

llvm-svn: 290168

show more ...

*** This commit represents a complete reformatting of the LLDB source code
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:

Firstly, merging t

*** This commit represents a complete reformatting of the LLDB source code
*** 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

show more ...

Now that there are no cycles that cause leaks in the disassembler/instruction classes, we can get rid of the FIXME lines that were working around this issue.

<rdar://problem/26684190>

llvm-svn: 272

Now that there are no cycles that cause leaks in the disassembler/instruction classes, we can get rid of the FIXME lines that were working around this issue.

<rdar://problem/26684190>

llvm-svn: 272071

show more ...

Keep original source path and mapped path in LineEntry

Summary:
The "file" variable in a LineEntry was mapped using target.source-map, except when stepping through inlined code. This patch adds a ne

Keep original source path and mapped path in LineEntry

Summary:
The "file" variable in a LineEntry was mapped using target.source-map, except when stepping through inlined code. This patch adds a new variable to LineEntry, "original_file", that contains the original file from the debug info. "file" will continue to (possibly) be mapped.

Some code has been changed to use "original_file". This is code dealing with symbols. Code dealing with source files will still use "file". Reviewers, please confirm that these particular changes are correct.

Tests run on Ubuntu 12.04 show no regression.

Reviewers: clayborg, jingham

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D20135

llvm-svn: 269250

show more ...

Fix Clang-tidy modernize-use-nullptr and readability-simplify-boolean-expr warnings in some files in source/Target/.

Simplify smart pointers checks in conditions. Other minor fixes.

llvm-svn: 255598

When constructing an address range to "step" or "next" through,
find the largest address range (possibly combining multiple
LineEntry's for this line number) that is contiguous.

This allows lldb's

When constructing an address range to "step" or "next" through,
find the largest address range (possibly combining multiple
LineEntry's for this line number) that is contiguous.

This allows lldb's fast-step stepping algorithm to potentially
run for a longer address range than if we have to stop at every
LineEntry indicating a subexpression in the source line.

http://reviews.llvm.org/D15407
<rdar://problem/23270882>

llvm-svn: 255590

show more ...

Fix commit 252963 to work around a bug on some platforms where they don't
correctly handle stepping over one breakpoint directly onto another breakpoint.
This isn't fixing that bug, but rather jus

Fix commit 252963 to work around a bug on some platforms where they don't
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

show more ...

Revert "Another little stepping optimization: if any of the source step commands are running through a range "

- Revert because this commit introduce several failures in lldb test suite
- http://lab

Revert "Another little stepping optimization: if any of the source step commands are running through a range "

- Revert because this commit introduce several failures in lldb test suite
- http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/8391
- This reverts commit 78943bb678c2893703ee4e8b41969372740c8a6f.

llvm-svn: 252980

show more ...

Another little stepping optimization: if any of the source step commands are running through a range
of addresses, and the range has no branches, instead of running to the last instruction and
singl

Another little stepping optimization: if any of the source step commands are running through a range
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

show more ...

Fix compiler warning in ThreadPlanStepRange

llvm-svn: 242403

Small fix to ThreadPlanStepRange::DumpRanges to logging
output when stepping through multiple ranges.

llvm-svn: 242243

Resubmitting 240466 after fixing the linux test suite failures.

A few extras were fixed

- Symbol::GetAddress() now returns an Address object, not a reference. There were places where people were ac

Resubmitting 240466 after fixing the linux test suite failures.

A few extras were fixed

- Symbol::GetAddress() now returns an Address object, not a reference. There were places where people were accessing the address of a symbol when the symbol's value wasn't an address symbol. On MacOSX, undefined symbols have a value zero and some places where using the symbol's address and getting an absolute address of zero (since an Address object with no section and an m_offset whose value isn't LLDB_INVALID_ADDRESS is considered an absolute address). So fixing this required some changes to make sure people were getting what they expected.
- Since some places want to access the address as a reference, I added a few new functions to symbol:
Address &Symbol::GetAddressRef();
const Address &Symbol::GetAddressRef() const;

Linux test suite passes just fine now.

<rdar://problem/21494354>

llvm-svn: 240702

show more ...

Add Hexagon packet support to ThreadPlanStepRange

Summary:
Hexagon is a VLIW processor. It can execute multiple instructions at once, called a packet. Breakpoints need to be alone in a packet. This

Add Hexagon packet support to ThreadPlanStepRange

Summary:
Hexagon is a VLIW processor. It can execute multiple instructions at once, called a packet. Breakpoints need to be alone in a packet. This patch will make sure that temporary breakpoints used for stepping are set at the start of a packet, which will put the breakpoint in a packet by itself.

Patch by Deepak Panickal of CodePlay and Ted Woodward of Qualcomm.

Reviewers: deepak2427, clayborg

Reviewed By: clayborg

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D9437

llvm-svn: 237047

show more ...

Move lldb-log.cpp to core/Logging.cpp

So that we don't have to update every single #include in the entire
codebase to #include this new header (which used to get included by
lldb-private-log.h, we a

Move lldb-log.cpp to core/Logging.cpp

So that we don't have to update every single #include in the entire
codebase to #include this new header (which used to get included by
lldb-private-log.h, we automatically #include "Logging.h" from
within "Log.h".

llvm-svn: 232653

show more ...

This checkin is the first step in making the lldb thread stepping mechanism more accessible from
the user level. It adds the ability to invent new stepping modes implemented by python classes,
and t

This checkin is the first step in making the lldb thread stepping mechanism more accessible from
the user level. It adds the ability to invent new stepping modes implemented by python classes,
and to view the current thread plan stack and to some extent alter it.

I haven't gotten to documentation or tests yet. But this should not cause any behavior changes
if you don't use it, so its safe to check it in now and work on it incrementally.

llvm-svn: 218642

show more ...

Fetching the parent frame may fail, handle that case. Patch from Tong Shen.

llvm-svn: 215411

When stepping, handle the case where the step leaves us with
the same parent frame, but different current frame - e.g. when
you step past a tail call exit from a function. Apply the same
"avoid-no-d

When stepping, handle the case where the step leaves us with
the same parent frame, but different current frame - e.g. when
you step past a tail call exit from a function. Apply the same
"avoid-no-debug" rules to this case as for a "step-in".

<rdar://problem/16189225>

llvm-svn: 214946

show more ...

Fix Windows build using portable types for formatting the log outputs

llvm-svn: 202723

Roll back the changes I made in r193907 which created a new Frame
pure virtual base class and made StackFrame a subclass of that. As
I started to build on top of that arrangement today, I found that

Roll back the changes I made in r193907 which created a new Frame
pure virtual base class and made StackFrame a subclass of that. As
I started to build on top of that arrangement today, I found that it
wasn't working out like I intended. Instead I'll try sticking with
the single StackFrame class -- there's too much code duplication to
make a more complicated class hierarchy sensible I think.

llvm-svn: 193983

show more ...

Add a new base class, Frame. It is a pure virtual function which
defines a protocol that all subclasses will implement. StackFrame
is currently the only subclass and the methods that Frame vends ar

Add a new base class, Frame. It is a pure virtual function which
defines a protocol that all subclasses will implement. StackFrame
is currently the only subclass and the methods that Frame vends are
nearly identical to StackFrame's old methods.

Update all callers to use Frame*/Frame& instead of pointers to
StackFrames.

This is almost entirely a mechanical change that touches a lot of
the code base so I'm committing it alone. No new functionality is
added with this patch, no new subclasses of Frame exist yet.

I'll probably need to tweak some of the separation, possibly moving
some of StackFrame's methods up in to Frame, but this is a good
starting point.

<rdar://problem/15314068>

llvm-svn: 193907

show more ...

<rdar://problem/13635174>

Added a way to set hardware breakpoints from the "breakpoint set" command with the new "--hardware" option. Hardware breakpoints are not a request, they currently are a req

<rdar://problem/13635174>

Added a way to set hardware breakpoints from the "breakpoint set" command with the new "--hardware" option. Hardware breakpoints are not a request, they currently are a requirement. So when breakpoints are specified as hardware breakpoints, they might fail to be set when they are able to be resolved and should be used sparingly. This is currently hooked up for GDB remote debugging.

Linux and FreeBSD should quickly enable this feature if possible, or return an error for any breakpoints that are hardware breakpoint sites in the "virtual Error Process::EnableBreakpointSite (BreakpointSite *bp_site);" function.

llvm-svn: 192491

show more ...

DWARF says line number 0 is a valid line number - used to indicate a source line that should
not have breakpoints set on it inserted into code that does have a valid line number. So allow
that line

DWARF says line number 0 is a valid line number - used to indicate a source line that should
not have breakpoints set on it inserted into code that does have a valid line number. So allow
that line number, and the ThreadPlanStepRange should just continue stepping over 0 line ranges
as if they had the same line number as whatever we were previously stepping through.

llvm-svn: 191477

show more ...

Disassembler::DisassembleRange() currently calls Target::ReadMemory
with prefer_file_cache == false. This is what we want to do when
the user is doing a disassemble command -- show the actual memory

Disassembler::DisassembleRange() currently calls Target::ReadMemory
with prefer_file_cache == false. This is what we want to do when
the user is doing a disassemble command -- show the actual memory
contents in case the memory has been corrupted or something -- but
when we're profiling functions for stepping or unwinding
(ThreadPlanStepRange::GetInstructionsForAddress,
UnwindAssemblyInstEmulation::GetNonCallSiteUnwindP) we can read
__TEXT instructions directly out of the file, if it exists.
<rdar://problem/14397491>

llvm-svn: 190638

show more ...

Re-enable fast stepping for arm targets. The issue being worked
around was fixed in llvm commit r186846.
<rdar://problem/14489274>

llvm-svn: 187620

The DisassemblerLLVMC has a retain cycle - the InstructionLLVMC's contained in its instruction
list have a shared pointer back to their DisassemblerLLVMC. This checkin force clears the InstructionLi

The DisassemblerLLVMC has a retain cycle - the InstructionLLVMC's contained in its instruction
list have a shared pointer back to their DisassemblerLLVMC. This checkin force clears the InstructionList
in all the places we use the DisassemblerSP to stop the leaking for now. I'll go back and fix this
for real when I have time to do so.

<rdar://problem/14581918>

llvm-svn: 187473

show more ...