[lldb] Rename Logging.h to LLDBLog.h and clean up includes

Most of our code was including Log.h even though that is not where the
"lldb" log channel is defined (Log.h defines the generic logging
inf

[lldb] Rename Logging.h to LLDBLog.h and clean up includes

Most of our code was including Log.h even though that is not where the
"lldb" log channel is defined (Log.h defines the generic logging
infrastructure). This worked because Log.h included Logging.h, even
though it should.

After the recent refactor, it became impossible the two files include
each other in this direction (the opposite inclusion is needed), so this
patch removes the workaround that was put in place and cleans up all
files to include the right thing. It also renames the file to LLDBLog to
better reflect its purpose.

show more ...

[lldb] Convert "LLDB" log channel to the new API

[lldb] [gdb-remote server] Introduce new stop reasons for fork and vfork

Introduce three new stop reasons for fork, vfork and vforkdone events.
This includes server support for serializing fork/vfor

[lldb] [gdb-remote server] Introduce new stop reasons for fork and vfork

Introduce three new stop reasons for fork, vfork and vforkdone events.
This includes server support for serializing fork/vfork events into
gdb-remote protocol. The stop infos for the two base events take a pair
of PID and TID for the newly forked process.

Differential Revision: https://reviews.llvm.org/D100196

show more ...

[lldb] Delete dead StackFrameList::Merge

That code is unused since it's check-in in 2010 (and I believe it would leak
memory when called as it releases the passed unique_ptr), so let's delete it.

R

[lldb] Delete dead StackFrameList::Merge

That code is unused since it's check-in in 2010 (and I believe it would leak
memory when called as it releases the passed unique_ptr), so let's delete it.

Reviewed By: vsk

Differential Revision: https://reviews.llvm.org/D100212

show more ...

LanguageRuntime for 0th frame unwind, simplify getting pc-for-symbolication

Add calls into LanguageRuntime when finding the unwind method to
use out of the 0th (currently executing) stack frame.

Al

LanguageRuntime for 0th frame unwind, simplify getting pc-for-symbolication

Add calls into LanguageRuntime when finding the unwind method to
use out of the 0th (currently executing) stack frame.

Allow for the LanguageRuntimes to indicate if this stack frames
should be treated like a zeroth-frame -- symbolication should be
done based on the saved pc address, not decremented like normal ABI
function calls.

Add methods to RegisterContext and StackFrame to get a pc value
suitable for symbolication, to reduce the number of places in lldb
where we decrement the saved pc values before symbolication.

<rdar://problem/70398009>
Differential Revision: https://reviews.llvm.org/D97644

show more ...

[lldb] Fix -Wmissing-field-initializers in StackFrameList

The code is correct without these default values, but it is freaking the
compiler out.

[lldb/DWARF] Fix PC value for artificial tail call frames for the "GNU" case

Summary:
The way that the support for the GNU dialect of tail call frames was
implemented in D80519 meant that the were r

[lldb/DWARF] Fix PC value for artificial tail call frames for the "GNU" case

Summary:
The way that the support for the GNU dialect of tail call frames was
implemented in D80519 meant that the were reporting very bogus PC values
which pointed into the middle of an instruction: the -1 trick is
necessary for the address to resolve to the right function, but we
should still be reporting a more realistic PC value -- I say "realistic"
and not "real", because it's very debatable what should be the correct
PC value for frames like this.

This patch achieves that my moving the -1 from SymbolFileDWARF into the
stack frame computation code. The idea is that SymbolFileDWARF will
merely report whether it has provided an address of the instruction
after the tail call, or the address of the call instruction itself. The
StackFrameList machinery uses this information to set the "behaves like
frame zero" property of the artificial frames (the main thing this flag
does is it controls the -1 subtraction when looking up the function
address).

This required a moderate refactor of the CallEdge class, because it was
implicitly assuming that edges pointing after the call were real calls
and those pointing the the call insn were tail calls. The class now
carries this information explicitly -- it carries three mostly
independent pieces of information:
- an address of interest in the caller
- a bit saying whether this address points to the call insn or after it
- whether this is a tail call

Reviewers: vsk, dblaikie

Subscribers: aprantl, mgrang, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D81010

show more ...

[lldb/DWARF] Reland: Use DW_AT_call_pc to determine artificial frame address

Reland with changes: the test modified in this change originally failed
on a Debian/x86_64 builder, and I suspect the cau

[lldb/DWARF] Reland: Use DW_AT_call_pc to determine artificial frame address

Reland with changes: the test modified in this change originally failed
on a Debian/x86_64 builder, and I suspect the cause was that lldb looked
up the line location for an artificial frame by subtracting 1 from the
frame's address. For artificial frames, the subtraction must not happen
because the address is already exact.

---

lldb currently guesses the address to use when creating an artificial
frame (i.e., a frame constructed by determining the sequence of (tail)
calls which must have happened).

Guessing the address creates problems -- use the actual address provided
by the DW_AT_call_pc attribute instead.

Depends on D76336.

rdar://60307600

Differential Revision: https://reviews.llvm.org/D76337

show more ...

Revert "[lldb/DWARF] Use DW_AT_call_pc to determine artificial frame address"

This reverts commit 6905394d153960ded3a7b884a9747ed2d4a6e8d8. The
changed test is failing on Debian/x86_64, possibly bec

Revert "[lldb/DWARF] Use DW_AT_call_pc to determine artificial frame address"

This reverts commit 6905394d153960ded3a7b884a9747ed2d4a6e8d8. The
changed test is failing on Debian/x86_64, possibly because lldb is
subtracting an offset from the DW_AT_call_pc address used for the
artificial frame:

http://lab.llvm.org:8011/builders/lldb-x86_64-debian/builds/7171/steps/test/logs/stdio

/home/worker/lldb-x86_64-debian/lldb-x86_64-debian/llvm-project/lldb/test/API/functionalities/tail_call_frames/unambiguous_sequence/main.cpp:6:17: error: CHECK-NEXT: expected string not found in input
// CHECK-NEXT: frame #1: 0x{{[0-9a-f]+}} a.out`func3() at main.cpp:14:3 [opt] [artificial]
^
<stdin>:3:2: note: scanning from here
frame #1: 0x0000000000401127 a.out`func3() at main.cpp:13:4 [opt] [artificial]

show more ...

[lldb/DWARF] Use DW_AT_call_pc to determine artificial frame address

lldb currently guesses the address to use when creating an artificial
frame (i.e., a frame constructed by determining the sequenc

[lldb/DWARF] Use DW_AT_call_pc to determine artificial frame address

lldb currently guesses the address to use when creating an artificial
frame (i.e., a frame constructed by determining the sequence of (tail)
calls which must have happened).

Guessing the address creates problems -- use the actual address provided
by the DW_AT_call_pc attribute instead.

Depends on D76336.

rdar://60307600

Differential Revision: https://reviews.llvm.org/D76337

show more ...

[lldb] Return Unwinder& from Thread::GetUnwinder

The function always returns a valid object. Let the return type reflect
that, and remove some null checks.

[lldb/StackFrameList] Convert assert to defensive check in SynthesizeTailCallFrames

In order to synthesize tail call frames, the stack frame list must not
be empty (otherwise, there is no "previous"

[lldb/StackFrameList] Convert assert to defensive check in SynthesizeTailCallFrames

In order to synthesize tail call frames, the stack frame list must not
be empty (otherwise, there is no "previous" frame to infer a tail call
from).

This case is hard to hit. To trigger it, we must first fail to push
`unwind_frame_sp` because we either fail to get its SymbolContext, or
given its SymbolContext the GetParentOfInlineScope call fails. This
causes m_concrete_frames_fetched to be incremented while m_frames
remains empty. Then, the next frame in the stack may fail within
SynthesizeTailCallFrames. This crash arose during a kernel debugging
session.

rdar://59147051

show more ...

[lldb][NFC] Fix all formatting errors in .cpp file headers

Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp ----------------------------------------

[lldb][NFC] Fix all formatting errors in .cpp file headers

Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp -------------------------------------------------===//
```
However in LLDB most of our source files have arbitrary changes to this format and
these changes are spreading through LLDB as folks usually just use the existing
source files as templates for their new files (most notably the unnecessary
editor language indicator `-*- C++ -*-` is spreading and in every review
someone is pointing out that this is wrong, resulting in people pointing out that this
is done in the same way in other files).

This patch removes most of these inconsistencies including the editor language indicators,
all the different missing/additional '-' characters, files that center the file name, missing
trailing `===//` (mostly caused by clang-format breaking the line).

Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere

Reviewed By: JDevlieghere

Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D73258

show more ...

[DWARF] Handle call sites with indirect call targets

Split CallEdge into DirectCallEdge and IndirectCallEdge. Teach
DWARFExpression how to evaluate entry values in cases where the current
activation

[DWARF] Handle call sites with indirect call targets

Split CallEdge into DirectCallEdge and IndirectCallEdge. Teach
DWARFExpression how to evaluate entry values in cases where the current
activation was created by an indirect call.

rdar://57094085

Differential Revision: https://reviews.llvm.org/D70100

show more ...

[StackFrameList][DFS] Turn a few raw pointers into references, NFC

llvm-svn: 373267

[Function] Factor out GetCallEdgeForReturnAddress, NFC

Finding the call edge in a function which corresponds to a particular
return address is a generic/useful operation.

llvm-svn: 371543

Fix PC adjustment in StackFrame::GetSymbolContext

Summary:
Update StackFrame::GetSymbolContext to mirror the logic in
RegisterContextLLDB::InitializeNonZerothFrame that knows not to do the
pc decrem

Fix PC adjustment in StackFrame::GetSymbolContext

Summary:
Update StackFrame::GetSymbolContext to mirror the logic in
RegisterContextLLDB::InitializeNonZerothFrame that knows not to do the
pc decrement when the given frame is a signal trap handler frame or the
parent of one, because the pc may not follow a call in these frames.
Accomplish this by adding a behaves_like_zeroth_frame field to
lldb_private::StackFrame, set to true for the zeroth frame, for
signal handler frames, and for parents of signal handler frames.

Also add logic to propagate the signal handler flag from UnwindPlan to
the FrameType on the RegisterContextLLDB it generates, and factor out a
helper to resolve symbol and address range for an Address now that we
need to invoke it in four places.

Reviewers: jasonmolenda, clayborg, jfb

Reviewed By: jasonmolenda

Subscribers: labath, dexonsmith, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D64993

llvm-svn: 367691

show more ...

[Logging] Replace Log::Printf with LLDB_LOG macro (NFC)

This patch replaces explicit calls to log::Printf with the new LLDB_LOGF
macro. The macro is similar to LLDB_LOG but supports printf-style for

[Logging] Replace Log::Printf with LLDB_LOG macro (NFC)

This patch replaces explicit calls to log::Printf with the new LLDB_LOGF
macro. The macro is similar to LLDB_LOG but supports printf-style format
strings, instead of formatv-style format strings.

So instead of writing:

if (log)
log->Printf("%s\n", str);

You'd write:

LLDB_LOG(log, "%s\n", str);

This change was done mechanically with the command below. I replaced the
spurious if-checks with vim, since I know how to do multi-line
replacements with it.

find . -type f -name '*.cpp' -exec \
sed -i '' -E 's/log->Printf\(/LLDB_LOGF\(log, /g' "{}" +

Differential revision: https://reviews.llvm.org/D65128

llvm-svn: 366936

show more ...

[NFC] Remove ASCII lines from comments

A lot of comments in LLDB are surrounded by an ASCII line to delimit the
begging and end of the comment.

Its use is not really consistent across the code base

[NFC] Remove ASCII lines from comments

A lot of comments in LLDB are surrounded by an ASCII line to delimit the
begging and end of the comment.

Its use is not really consistent across the code base, sometimes the
lines are longer, sometimes they are shorter and sometimes they are
omitted. Furthermore, it looks kind of weird with the 80 column limit,
where the comment actually extends past the line, but not by much.
Furthermore, when /// is used for Doxygen comments, it looks
particularly odd. And when // is used, it incorrectly gives the
impression that it's actually a Doxygen comment.

I assume these lines were added to improve distinguishing between
comments and code. However, given that todays editors and IDEs do a
great job at highlighting comments, I think it's worth to drop this for
the sake of consistency. The alternative is fixing all the
inconsistencies, which would create a lot more churn.

Differential revision: https://reviews.llvm.org/D60508

llvm-svn: 358135

show more ...

Replace 'ap' with 'up' suffix in variable names. (NFC)

The `ap` suffix is a remnant of lldb's former use of auto pointers,
before they got deprecated. Although all their uses were replaced by
unique

Replace 'ap' with 'up' suffix in variable names. (NFC)

The `ap` suffix is a remnant of lldb's former use of auto pointers,
before they got deprecated. Although all their uses were replaced by
unique pointers, some variables still carried the suffix.

In r353795 I removed another auto_ptr remnant, namely redundant calls to
::get for unique_pointers. Jim justly noted that this is a good
opportunity to clean up the variable names as well.

I went over all the changes to ensure my find-and-replace didn't have
any undesired side-effects. I hope I didn't miss any, but if you end up
at this commit doing a git blame on a weirdly named variable, please
know that the change was unintentional.

llvm-svn: 353912

show more ...

Use std::make_shared in LLDB (NFC)

Unlike std::make_unique, which is only available since C++14,
std::make_shared is available since C++11. Not only is std::make_shared
a lot more readable compared

Use std::make_shared in LLDB (NFC)

Unlike std::make_unique, which is only available since C++14,
std::make_shared is available since C++11. Not only is std::make_shared
a lot more readable compared to ::reset(new), it also performs a single
heap allocation for the object and control block.

Differential revision: https://reviews.llvm.org/D57990

llvm-svn: 353764

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

Remove header grouping comments.

This patch removes the comments grouping header includes. They were
added after running IWYU over the LLDB codebase. However they add little
value, are often outdate

Remove header grouping comments.

This patch removes the comments grouping header includes. They were
added after running IWYU over the LLDB codebase. However they add little
value, are often outdates and burdensome to maintain.

llvm-svn: 346626

show more ...

Add support for artificial tail call frames

This patch teaches lldb to detect when there are missing frames in a
backtrace due to a sequence of tail calls, and to fill in the backtrace
with artifici

Add support for artificial tail call frames

This patch teaches lldb to detect when there are missing frames in a
backtrace due to a sequence of tail calls, and to fill in the backtrace
with artificial tail call frames when this happens. This is only done
when the execution history can be determined from the call graph and
from the return PC addresses of calls on the stack. Ambiguous sequences
of tail calls (e.g anything involving tail calls and recursion) are
detected and ignored.

Depends on D49887.

Differential Revision: https://reviews.llvm.org/D50478

llvm-svn: 343900

show more ...

[StackFrame] Add more clarifying comments to StackFrameList (NFC)

llvm-svn: 339205