[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
2020-01-24 15:23:27 +08:00
|
|
|
//===-- UnwindLLDB.cpp ----------------------------------------------------===//
|
2010-10-25 19:12:07 +08:00
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2010-10-25 19:12:07 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2020-03-09 21:36:15 +08:00
|
|
|
#include "lldb/Target/UnwindLLDB.h"
|
2010-10-25 19:12:07 +08:00
|
|
|
#include "lldb/Core/Module.h"
|
|
|
|
#include "lldb/Symbol/FuncUnwinders.h"
|
|
|
|
#include "lldb/Symbol/Function.h"
|
|
|
|
#include "lldb/Symbol/UnwindPlan.h"
|
2015-03-04 03:23:09 +08:00
|
|
|
#include "lldb/Target/ABI.h"
|
2011-04-26 02:36:36 +08:00
|
|
|
#include "lldb/Target/Process.h"
|
|
|
|
#include "lldb/Target/RegisterContext.h"
|
2020-03-09 21:36:15 +08:00
|
|
|
#include "lldb/Target/RegisterContextUnwind.h"
|
2011-04-26 02:36:36 +08:00
|
|
|
#include "lldb/Target/Target.h"
|
|
|
|
#include "lldb/Target/Thread.h"
|
2022-02-03 20:26:10 +08:00
|
|
|
#include "lldb/Utility/LLDBLog.h"
|
2017-03-04 04:56:28 +08:00
|
|
|
#include "lldb/Utility/Log.h"
|
2010-10-25 19:12:07 +08:00
|
|
|
|
|
|
|
using namespace lldb;
|
|
|
|
using namespace lldb_private;
|
|
|
|
|
|
|
|
UnwindLLDB::UnwindLLDB(Thread &thread)
|
2014-02-14 13:06:49 +08:00
|
|
|
: Unwind(thread), m_frames(), m_unwind_complete(false),
|
|
|
|
m_user_supplied_trap_handler_functions() {
|
|
|
|
ProcessSP process_sp(thread.GetProcess());
|
|
|
|
if (process_sp) {
|
|
|
|
Args args;
|
|
|
|
process_sp->GetTarget().GetUserSpecifiedTrapHandlerNames(args);
|
|
|
|
size_t count = args.GetArgumentCount();
|
|
|
|
for (size_t i = 0; i < count; i++) {
|
|
|
|
const char *func_name = args.GetArgumentAtIndex(i);
|
|
|
|
m_user_supplied_trap_handler_functions.push_back(ConstString(func_name));
|
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2010-10-25 19:12:07 +08:00
|
|
|
}
|
|
|
|
|
2011-10-21 09:49:48 +08:00
|
|
|
uint32_t UnwindLLDB::DoGetFrameCount() {
|
2012-02-29 11:40:22 +08:00
|
|
|
if (!m_unwind_complete) {
|
2011-01-07 14:08:19 +08:00
|
|
|
//#define DEBUG_FRAME_SPEED 1
|
|
|
|
#if DEBUG_FRAME_SPEED
|
2011-01-10 05:07:35 +08:00
|
|
|
#define FRAME_COUNT 10000
|
2016-11-02 18:27:54 +08:00
|
|
|
using namespace std::chrono;
|
|
|
|
auto time_value = steady_clock::now();
|
2011-01-07 14:08:19 +08:00
|
|
|
#endif
|
2010-11-09 10:31:21 +08:00
|
|
|
if (!AddFirstFrame())
|
2010-10-25 19:12:07 +08:00
|
|
|
return 0;
|
2011-05-25 07:06:02 +08:00
|
|
|
|
2012-02-21 08:09:25 +08:00
|
|
|
ProcessSP process_sp(m_thread.GetProcess());
|
[lldb] NFC modernize codebase with modernize-use-nullptr
Summary:
NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]
This commit is the result of modernizing the LLDB codebase by using
`nullptr` instread of `0` or `NULL`. See
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html
for more information.
This is the command I ran and I to fix and format the code base:
```
run-clang-tidy.py \
-header-filter='.*' \
-checks='-*,modernize-use-nullptr' \
-fix ~/dev/llvm-project/lldb/.* \
-format \
-style LLVM \
-p ~/llvm-builds/debug-ninja-gcc
```
NOTE: There were also changes to `llvm/utils/unittest` but I did not
include them because I felt that maybe this library shall be updated in
isolation somehow.
NOTE: I know this is a rather large commit but it is a nobrainer in most
parts.
Reviewers: martong, espindola, shafik, #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D61847
llvm-svn: 361484
2019-05-23 19:14:47 +08:00
|
|
|
ABI *abi = process_sp ? process_sp->GetABI().get() : nullptr;
|
2011-05-25 07:06:02 +08:00
|
|
|
|
|
|
|
while (AddOneMoreFrame(abi)) {
|
2011-01-07 14:08:19 +08:00
|
|
|
#if DEBUG_FRAME_SPEED
|
2011-01-10 05:07:35 +08:00
|
|
|
if ((m_frames.size() % FRAME_COUNT) == 0) {
|
2016-11-02 18:27:54 +08:00
|
|
|
const auto now = steady_clock::now();
|
|
|
|
const auto delta_t = now - time_value;
|
|
|
|
printf("%u frames in %.9f ms (%g frames/sec)\n", FRAME_COUNT,
|
|
|
|
duration<double, std::milli>(delta_t).count(),
|
|
|
|
(float)FRAME_COUNT / duration<double>(delta_t).count());
|
2011-01-07 14:08:19 +08:00
|
|
|
time_value = now;
|
|
|
|
}
|
|
|
|
#endif
|
2010-11-09 10:31:21 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2010-11-09 10:31:21 +08:00
|
|
|
return m_frames.size();
|
|
|
|
}
|
|
|
|
|
|
|
|
bool UnwindLLDB::AddFirstFrame() {
|
2012-02-29 11:40:22 +08:00
|
|
|
if (m_frames.size() > 0)
|
|
|
|
return true;
|
Fix to solve Bug 23139 & Bug 23560
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
2015-11-13 18:47:49 +08:00
|
|
|
|
2012-01-30 04:56:30 +08:00
|
|
|
ProcessSP process_sp(m_thread.GetProcess());
|
[lldb] NFC modernize codebase with modernize-use-nullptr
Summary:
NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]
This commit is the result of modernizing the LLDB codebase by using
`nullptr` instread of `0` or `NULL`. See
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html
for more information.
This is the command I ran and I to fix and format the code base:
```
run-clang-tidy.py \
-header-filter='.*' \
-checks='-*,modernize-use-nullptr' \
-fix ~/dev/llvm-project/lldb/.* \
-format \
-style LLVM \
-p ~/llvm-builds/debug-ninja-gcc
```
NOTE: There were also changes to `llvm/utils/unittest` but I did not
include them because I felt that maybe this library shall be updated in
isolation somehow.
NOTE: I know this is a rather large commit but it is a nobrainer in most
parts.
Reviewers: martong, espindola, shafik, #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D61847
llvm-svn: 361484
2019-05-23 19:14:47 +08:00
|
|
|
ABI *abi = process_sp ? process_sp->GetABI().get() : nullptr;
|
2011-01-07 06:15:06 +08:00
|
|
|
|
2011-05-25 07:06:02 +08:00
|
|
|
// First, set up the 0th (initial) frame
|
2010-11-09 10:31:21 +08:00
|
|
|
CursorSP first_cursor_sp(new Cursor());
|
2020-03-09 21:36:15 +08:00
|
|
|
RegisterContextLLDBSP reg_ctx_sp(new RegisterContextUnwind(
|
2011-05-25 07:06:02 +08:00
|
|
|
m_thread, RegisterContextLLDBSP(), first_cursor_sp->sctx, 0, *this));
|
[lldb] NFC modernize codebase with modernize-use-nullptr
Summary:
NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]
This commit is the result of modernizing the LLDB codebase by using
`nullptr` instread of `0` or `NULL`. See
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html
for more information.
This is the command I ran and I to fix and format the code base:
```
run-clang-tidy.py \
-header-filter='.*' \
-checks='-*,modernize-use-nullptr' \
-fix ~/dev/llvm-project/lldb/.* \
-format \
-style LLVM \
-p ~/llvm-builds/debug-ninja-gcc
```
NOTE: There were also changes to `llvm/utils/unittest` but I did not
include them because I felt that maybe this library shall be updated in
isolation somehow.
NOTE: I know this is a rather large commit but it is a nobrainer in most
parts.
Reviewers: martong, espindola, shafik, #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D61847
llvm-svn: 361484
2019-05-23 19:14:47 +08:00
|
|
|
if (reg_ctx_sp.get() == nullptr)
|
2012-02-29 11:40:22 +08:00
|
|
|
goto unwind_done;
|
2011-01-07 06:15:06 +08:00
|
|
|
|
2011-05-25 07:06:02 +08:00
|
|
|
if (!reg_ctx_sp->IsValid())
|
2012-02-29 11:40:22 +08:00
|
|
|
goto unwind_done;
|
2011-01-07 06:15:06 +08:00
|
|
|
|
2012-01-30 04:56:30 +08:00
|
|
|
if (!reg_ctx_sp->GetCFA(first_cursor_sp->cfa))
|
2010-11-09 10:31:21 +08:00
|
|
|
goto unwind_done;
|
Fix to solve Bug 23139 & Bug 23560
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
2015-11-13 18:47:49 +08:00
|
|
|
|
|
|
|
if (!reg_ctx_sp->ReadPC(first_cursor_sp->start_pc))
|
|
|
|
goto unwind_done;
|
|
|
|
|
2011-01-07 06:15:06 +08:00
|
|
|
// Everything checks out, so release the auto pointer value and let the
|
|
|
|
// cursor own it in its shared pointer
|
2012-01-30 04:56:30 +08:00
|
|
|
first_cursor_sp->reg_ctx_lldb_sp = reg_ctx_sp;
|
2010-11-09 10:31:21 +08:00
|
|
|
m_frames.push_back(first_cursor_sp);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
Fix to solve Bug 23139 & Bug 23560
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
2015-11-13 18:47:49 +08:00
|
|
|
// Update the Full Unwind Plan for this frame if not valid
|
|
|
|
UpdateUnwindPlanForFirstFrameIfInvalid(abi);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2010-11-09 10:31:21 +08:00
|
|
|
return true;
|
2013-12-20 09:05:11 +08:00
|
|
|
|
2012-02-29 11:40:22 +08:00
|
|
|
unwind_done:
|
2022-01-31 22:57:48 +08:00
|
|
|
Log *log = GetLog(LLDBLog::Unwind);
|
2013-12-20 09:05:11 +08:00
|
|
|
if (log) {
|
2019-07-25 01:56:10 +08:00
|
|
|
LLDB_LOGF(log, "th%d Unwind of this thread is complete.",
|
|
|
|
m_thread.GetIndexID());
|
2013-12-20 09:05:11 +08:00
|
|
|
}
|
2012-02-29 11:40:22 +08:00
|
|
|
m_unwind_complete = true;
|
|
|
|
return false;
|
2010-11-09 10:31:21 +08:00
|
|
|
}
|
|
|
|
|
2015-07-06 17:24:20 +08:00
|
|
|
UnwindLLDB::CursorSP UnwindLLDB::GetOneMoreFrame(ABI *abi) {
|
|
|
|
assert(m_frames.size() != 0 &&
|
|
|
|
"Get one more frame called with empty frame list");
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-02-29 11:40:22 +08:00
|
|
|
// If we've already gotten to the end of the stack, don't bother to try
|
|
|
|
// again...
|
|
|
|
if (m_unwind_complete)
|
2015-07-06 17:24:20 +08:00
|
|
|
return nullptr;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2022-01-31 22:57:48 +08:00
|
|
|
Log *log = GetLog(LLDBLog::Unwind);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2015-07-06 17:24:20 +08:00
|
|
|
CursorSP prev_frame = m_frames.back();
|
|
|
|
uint32_t cur_idx = m_frames.size();
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2015-07-06 17:24:20 +08:00
|
|
|
CursorSP cursor_sp(new Cursor());
|
2020-03-09 21:36:15 +08:00
|
|
|
RegisterContextLLDBSP reg_ctx_sp(new RegisterContextUnwind(
|
2015-07-06 17:24:20 +08:00
|
|
|
m_thread, prev_frame->reg_ctx_lldb_sp, cursor_sp->sctx, cur_idx, *this));
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2018-09-26 05:01:54 +08:00
|
|
|
uint64_t max_stack_depth = m_thread.GetMaxBacktraceDepth();
|
|
|
|
|
2015-07-06 17:24:20 +08:00
|
|
|
// We want to detect an unwind that cycles erroneously and stop backtracing.
|
2013-05-03 12:48:41 +08:00
|
|
|
// Don't want this maximum unwind limit to be too low -- if you have a
|
2018-05-01 00:49:04 +08:00
|
|
|
// backtrace with an "infinitely recursing" bug, it will crash when the stack
|
|
|
|
// blows out and the first 35,000 frames are uninteresting - it's the top
|
|
|
|
// most 5 frames that you actually care about. So you can't just cap the
|
|
|
|
// unwind at 10,000 or something. Realistically anything over around 200,000
|
|
|
|
// is going to blow out the stack space. If we're still unwinding at that
|
|
|
|
// point, we're probably never going to finish.
|
2018-09-26 05:01:54 +08:00
|
|
|
if (cur_idx >= max_stack_depth) {
|
2019-07-25 01:56:10 +08:00
|
|
|
LLDB_LOGF(log,
|
|
|
|
"%*sFrame %d unwound too many frames, assuming unwind has "
|
|
|
|
"gone astray, stopping.",
|
|
|
|
cur_idx < 100 ? cur_idx : 100, "", cur_idx);
|
2015-07-06 17:24:20 +08:00
|
|
|
return nullptr;
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
|
[lldb] NFC modernize codebase with modernize-use-nullptr
Summary:
NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]
This commit is the result of modernizing the LLDB codebase by using
`nullptr` instread of `0` or `NULL`. See
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html
for more information.
This is the command I ran and I to fix and format the code base:
```
run-clang-tidy.py \
-header-filter='.*' \
-checks='-*,modernize-use-nullptr' \
-fix ~/dev/llvm-project/lldb/.* \
-format \
-style LLVM \
-p ~/llvm-builds/debug-ninja-gcc
```
NOTE: There were also changes to `llvm/utils/unittest` but I did not
include them because I felt that maybe this library shall be updated in
isolation somehow.
NOTE: I know this is a rather large commit but it is a nobrainer in most
parts.
Reviewers: martong, espindola, shafik, #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D61847
llvm-svn: 361484
2019-05-23 19:14:47 +08:00
|
|
|
if (reg_ctx_sp.get() == nullptr) {
|
2020-03-09 21:36:15 +08:00
|
|
|
// If the RegisterContextUnwind has a fallback UnwindPlan, it will switch to
|
2018-05-01 00:49:04 +08:00
|
|
|
// that and return true. Subsequent calls to TryFallbackUnwindPlan() will
|
|
|
|
// return false.
|
2015-07-06 17:24:20 +08:00
|
|
|
if (prev_frame->reg_ctx_lldb_sp->TryFallbackUnwindPlan()) {
|
Fix to solve Bug 23139 & Bug 23560
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
2015-11-13 18:47:49 +08:00
|
|
|
// TryFallbackUnwindPlan for prev_frame succeeded and updated
|
2018-05-01 00:49:04 +08:00
|
|
|
// reg_ctx_lldb_sp field of prev_frame. However, cfa field of prev_frame
|
|
|
|
// still needs to be updated. Hence updating it.
|
Fix to solve Bug 23139 & Bug 23560
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
2015-11-13 18:47:49 +08:00
|
|
|
if (!(prev_frame->reg_ctx_lldb_sp->GetCFA(prev_frame->cfa)))
|
2015-07-06 17:24:20 +08:00
|
|
|
return nullptr;
|
|
|
|
|
2013-12-20 09:05:11 +08:00
|
|
|
return GetOneMoreFrame(abi);
|
|
|
|
}
|
2010-11-09 10:31:21 +08:00
|
|
|
|
2019-07-25 01:56:10 +08:00
|
|
|
LLDB_LOGF(log, "%*sFrame %d did not get a RegisterContext, stopping.",
|
|
|
|
cur_idx < 100 ? cur_idx : 100, "", cur_idx);
|
Fix to solve Bug 23139 & Bug 23560
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
2015-11-13 18:47:49 +08:00
|
|
|
return nullptr;
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
|
2011-05-25 07:06:02 +08:00
|
|
|
if (!reg_ctx_sp->IsValid()) {
|
2018-05-01 00:49:04 +08:00
|
|
|
// We failed to get a valid RegisterContext. See if the regctx below this
|
|
|
|
// on the stack has a fallback unwind plan it can use. Subsequent calls to
|
|
|
|
// TryFallbackUnwindPlan() will return false.
|
2015-07-06 17:24:20 +08:00
|
|
|
if (prev_frame->reg_ctx_lldb_sp->TryFallbackUnwindPlan()) {
|
Fix to solve Bug 23139 & Bug 23560
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
2015-11-13 18:47:49 +08:00
|
|
|
// TryFallbackUnwindPlan for prev_frame succeeded and updated
|
2018-05-01 00:49:04 +08:00
|
|
|
// reg_ctx_lldb_sp field of prev_frame. However, cfa field of prev_frame
|
|
|
|
// still needs to be updated. Hence updating it.
|
Fix to solve Bug 23139 & Bug 23560
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
2015-11-13 18:47:49 +08:00
|
|
|
if (!(prev_frame->reg_ctx_lldb_sp->GetCFA(prev_frame->cfa)))
|
2015-07-06 17:24:20 +08:00
|
|
|
return nullptr;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2015-07-06 17:24:20 +08:00
|
|
|
return GetOneMoreFrame(abi);
|
2010-11-09 10:31:21 +08:00
|
|
|
}
|
2015-07-06 17:24:20 +08:00
|
|
|
|
2019-07-25 01:56:10 +08:00
|
|
|
LLDB_LOGF(log,
|
|
|
|
"%*sFrame %d invalid RegisterContext for this frame, "
|
|
|
|
"stopping stack walk",
|
|
|
|
cur_idx < 100 ? cur_idx : 100, "", cur_idx);
|
Fix to solve Bug 23139 & Bug 23560
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
2015-11-13 18:47:49 +08:00
|
|
|
return nullptr;
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2011-05-25 07:06:02 +08:00
|
|
|
if (!reg_ctx_sp->GetCFA(cursor_sp->cfa)) {
|
2020-03-09 21:36:15 +08:00
|
|
|
// If the RegisterContextUnwind has a fallback UnwindPlan, it will switch to
|
2018-05-01 00:49:04 +08:00
|
|
|
// that and return true. Subsequent calls to TryFallbackUnwindPlan() will
|
|
|
|
// return false.
|
2015-07-06 17:24:20 +08:00
|
|
|
if (prev_frame->reg_ctx_lldb_sp->TryFallbackUnwindPlan()) {
|
Fix to solve Bug 23139 & Bug 23560
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
2015-11-13 18:47:49 +08:00
|
|
|
// TryFallbackUnwindPlan for prev_frame succeeded and updated
|
2018-05-01 00:49:04 +08:00
|
|
|
// reg_ctx_lldb_sp field of prev_frame. However, cfa field of prev_frame
|
|
|
|
// still needs to be updated. Hence updating it.
|
Fix to solve Bug 23139 & Bug 23560
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
2015-11-13 18:47:49 +08:00
|
|
|
if (!(prev_frame->reg_ctx_lldb_sp->GetCFA(prev_frame->cfa)))
|
2015-07-06 17:24:20 +08:00
|
|
|
return nullptr;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2015-07-06 17:24:20 +08:00
|
|
|
return GetOneMoreFrame(abi);
|
2010-11-09 10:31:21 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2019-07-25 01:56:10 +08:00
|
|
|
LLDB_LOGF(log,
|
|
|
|
"%*sFrame %d did not get CFA for this frame, stopping stack walk",
|
|
|
|
cur_idx < 100 ? cur_idx : 100, "", cur_idx);
|
2014-11-22 09:52:03 +08:00
|
|
|
return nullptr;
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2014-11-22 09:52:03 +08:00
|
|
|
if (abi && !abi->CallFrameAddressIsValid(cursor_sp->cfa)) {
|
|
|
|
// On Mac OS X, the _sigtramp asynchronous signal trampoline frame may not
|
2018-05-01 00:49:04 +08:00
|
|
|
// have its (constructed) CFA aligned correctly -- don't do the abi
|
|
|
|
// alignment check for these.
|
2018-12-15 08:15:33 +08:00
|
|
|
if (!reg_ctx_sp->IsTrapHandlerFrame()) {
|
Fix to solve Bug 23139 & Bug 23560
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
2015-11-13 18:47:49 +08:00
|
|
|
// See if we can find a fallback unwind plan for THIS frame. It may be
|
2014-11-22 09:52:03 +08:00
|
|
|
// that the UnwindPlan we're using for THIS frame was bad and gave us a
|
2018-05-01 00:49:04 +08:00
|
|
|
// bad CFA. If that's not it, then see if we can change the UnwindPlan
|
|
|
|
// for the frame below us ("NEXT") -- see if using that other UnwindPlan
|
|
|
|
// gets us a better unwind state.
|
2018-12-15 08:15:33 +08:00
|
|
|
if (!reg_ctx_sp->TryFallbackUnwindPlan() ||
|
|
|
|
!reg_ctx_sp->GetCFA(cursor_sp->cfa) ||
|
|
|
|
!abi->CallFrameAddressIsValid(cursor_sp->cfa)) {
|
2015-07-06 17:24:20 +08:00
|
|
|
if (prev_frame->reg_ctx_lldb_sp->TryFallbackUnwindPlan()) {
|
Fix to solve Bug 23139 & Bug 23560
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
2015-11-13 18:47:49 +08:00
|
|
|
// TryFallbackUnwindPlan for prev_frame succeeded and updated
|
2018-05-01 00:49:04 +08:00
|
|
|
// reg_ctx_lldb_sp field of prev_frame. However, cfa field of
|
|
|
|
// prev_frame still needs to be updated. Hence updating it.
|
Fix to solve Bug 23139 & Bug 23560
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
2015-11-13 18:47:49 +08:00
|
|
|
if (!(prev_frame->reg_ctx_lldb_sp->GetCFA(prev_frame->cfa)))
|
|
|
|
return nullptr;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2015-07-06 17:24:20 +08:00
|
|
|
return GetOneMoreFrame(abi);
|
Fix to solve Bug 23139 & Bug 23560
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
2015-11-13 18:47:49 +08:00
|
|
|
}
|
2015-07-06 17:24:20 +08:00
|
|
|
|
2019-07-25 01:56:10 +08:00
|
|
|
LLDB_LOGF(log,
|
|
|
|
"%*sFrame %d did not get a valid CFA for this frame, "
|
|
|
|
"stopping stack walk",
|
|
|
|
cur_idx < 100 ? cur_idx : 100, "", cur_idx);
|
2015-07-06 17:24:20 +08:00
|
|
|
return nullptr;
|
Fix to solve Bug 23139 & Bug 23560
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
2015-11-13 18:47:49 +08:00
|
|
|
} else {
|
2019-07-25 01:56:10 +08:00
|
|
|
LLDB_LOGF(log,
|
|
|
|
"%*sFrame %d had a bad CFA value but we switched the "
|
|
|
|
"UnwindPlan being used and got one that looks more "
|
|
|
|
"realistic.",
|
|
|
|
cur_idx < 100 ? cur_idx : 100, "", cur_idx);
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2011-05-25 07:06:02 +08:00
|
|
|
if (!reg_ctx_sp->ReadPC(cursor_sp->start_pc)) {
|
2020-03-09 21:36:15 +08:00
|
|
|
// If the RegisterContextUnwind has a fallback UnwindPlan, it will switch to
|
2018-05-01 00:49:04 +08:00
|
|
|
// that and return true. Subsequent calls to TryFallbackUnwindPlan() will
|
|
|
|
// return false.
|
2015-07-06 17:24:20 +08:00
|
|
|
if (prev_frame->reg_ctx_lldb_sp->TryFallbackUnwindPlan()) {
|
Fix to solve Bug 23139 & Bug 23560
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
2015-11-13 18:47:49 +08:00
|
|
|
// TryFallbackUnwindPlan for prev_frame succeeded and updated
|
2018-05-01 00:49:04 +08:00
|
|
|
// reg_ctx_lldb_sp field of prev_frame. However, cfa field of prev_frame
|
|
|
|
// still needs to be updated. Hence updating it.
|
Fix to solve Bug 23139 & Bug 23560
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
2015-11-13 18:47:49 +08:00
|
|
|
if (!(prev_frame->reg_ctx_lldb_sp->GetCFA(prev_frame->cfa)))
|
2015-07-06 17:24:20 +08:00
|
|
|
return nullptr;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2015-07-06 17:24:20 +08:00
|
|
|
return GetOneMoreFrame(abi);
|
2011-05-25 07:06:02 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2019-07-25 01:56:10 +08:00
|
|
|
LLDB_LOGF(log,
|
|
|
|
"%*sFrame %d did not get PC for this frame, stopping stack walk",
|
|
|
|
cur_idx < 100 ? cur_idx : 100, "", cur_idx);
|
2015-07-06 17:24:20 +08:00
|
|
|
return nullptr;
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2015-07-06 17:24:20 +08:00
|
|
|
if (abi && !abi->CodeAddressIsValid(cursor_sp->start_pc)) {
|
2020-03-09 21:36:15 +08:00
|
|
|
// If the RegisterContextUnwind has a fallback UnwindPlan, it will switch to
|
2018-05-01 00:49:04 +08:00
|
|
|
// that and return true. Subsequent calls to TryFallbackUnwindPlan() will
|
|
|
|
// return false.
|
2015-07-06 17:24:20 +08:00
|
|
|
if (prev_frame->reg_ctx_lldb_sp->TryFallbackUnwindPlan()) {
|
|
|
|
// TryFallbackUnwindPlan for prev_frame succeeded and updated
|
2018-05-01 00:49:04 +08:00
|
|
|
// reg_ctx_lldb_sp field of prev_frame. However, cfa field of prev_frame
|
|
|
|
// still needs to be updated. Hence updating it.
|
Fix to solve Bug 23139 & Bug 23560
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
2015-11-13 18:47:49 +08:00
|
|
|
if (!(prev_frame->reg_ctx_lldb_sp->GetCFA(prev_frame->cfa)))
|
2015-07-06 17:24:20 +08:00
|
|
|
return nullptr;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2015-07-06 17:24:20 +08:00
|
|
|
return GetOneMoreFrame(abi);
|
2013-12-20 09:05:11 +08:00
|
|
|
}
|
2013-09-26 22:35:59 +08:00
|
|
|
|
2019-07-25 01:56:10 +08:00
|
|
|
LLDB_LOGF(log, "%*sFrame %d did not get a valid PC, stopping stack walk",
|
|
|
|
cur_idx < 100 ? cur_idx : 100, "", cur_idx);
|
2015-07-06 17:24:20 +08:00
|
|
|
return nullptr;
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2015-07-06 17:24:20 +08:00
|
|
|
// Infinite loop where the current cursor is the same as the previous one...
|
|
|
|
if (prev_frame->start_pc == cursor_sp->start_pc &&
|
|
|
|
prev_frame->cfa == cursor_sp->cfa) {
|
2019-07-25 01:56:10 +08:00
|
|
|
LLDB_LOGF(log,
|
|
|
|
"th%d pc of this frame is the same as the previous frame and "
|
|
|
|
"CFAs for both frames are identical -- stopping unwind",
|
|
|
|
m_thread.GetIndexID());
|
2015-07-06 17:24:20 +08:00
|
|
|
return nullptr;
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
|
2012-01-30 04:56:30 +08:00
|
|
|
cursor_sp->reg_ctx_lldb_sp = reg_ctx_sp;
|
2015-07-06 17:24:20 +08:00
|
|
|
return cursor_sp;
|
|
|
|
}
|
|
|
|
|
Fix to solve Bug 23139 & Bug 23560
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
2015-11-13 18:47:49 +08:00
|
|
|
void UnwindLLDB::UpdateUnwindPlanForFirstFrameIfInvalid(ABI *abi) {
|
|
|
|
// This function is called for First Frame only.
|
|
|
|
assert(m_frames.size() == 1 && "No. of cursor frames are not 1");
|
|
|
|
|
|
|
|
bool old_m_unwind_complete = m_unwind_complete;
|
|
|
|
CursorSP old_m_candidate_frame = m_candidate_frame;
|
|
|
|
|
2015-07-06 17:24:20 +08:00
|
|
|
// Try to unwind 2 more frames using the Unwinder. It uses Full UnwindPlan
|
2018-05-01 00:49:04 +08:00
|
|
|
// and if Full UnwindPlan fails, then uses FallBack UnwindPlan. Also update
|
|
|
|
// the cfa of Frame 0 (if required).
|
2015-07-06 17:24:20 +08:00
|
|
|
AddOneMoreFrame(abi);
|
|
|
|
|
2018-05-01 00:49:04 +08:00
|
|
|
// Remove all the frames added by above function as the purpose of using
|
|
|
|
// above function was just to check whether Unwinder of Frame 0 works or not.
|
2015-07-06 17:24:20 +08:00
|
|
|
for (uint32_t i = 1; i < m_frames.size(); i++)
|
|
|
|
m_frames.pop_back();
|
|
|
|
|
|
|
|
// Restore status after calling AddOneMoreFrame
|
|
|
|
m_unwind_complete = old_m_unwind_complete;
|
|
|
|
m_candidate_frame = old_m_candidate_frame;
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2015-07-06 17:24:20 +08:00
|
|
|
|
|
|
|
bool UnwindLLDB::AddOneMoreFrame(ABI *abi) {
|
2022-01-31 22:57:48 +08:00
|
|
|
Log *log = GetLog(LLDBLog::Unwind);
|
2015-07-06 17:24:20 +08:00
|
|
|
|
|
|
|
// Frame zero is a little different
|
|
|
|
if (m_frames.empty())
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// If we've already gotten to the end of the stack, don't bother to try
|
2016-09-07 04:57:50 +08:00
|
|
|
// again...
|
2015-07-06 17:24:20 +08:00
|
|
|
if (m_unwind_complete)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
CursorSP new_frame = m_candidate_frame;
|
|
|
|
if (new_frame == nullptr)
|
|
|
|
new_frame = GetOneMoreFrame(abi);
|
|
|
|
|
|
|
|
if (new_frame == nullptr) {
|
2019-07-25 01:56:10 +08:00
|
|
|
LLDB_LOGF(log, "th%d Unwind of this thread is complete.",
|
|
|
|
m_thread.GetIndexID());
|
2015-07-06 17:24:20 +08:00
|
|
|
m_unwind_complete = true;
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
m_frames.push_back(new_frame);
|
|
|
|
|
2018-05-01 00:49:04 +08:00
|
|
|
// If we can get one more frame further then accept that we get back a
|
|
|
|
// correct frame.
|
Fix to solve Bug 23139 & Bug 23560
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
2015-11-13 18:47:49 +08:00
|
|
|
m_candidate_frame = GetOneMoreFrame(abi);
|
2015-07-06 17:24:20 +08:00
|
|
|
if (m_candidate_frame)
|
|
|
|
return true;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
Fix to solve Bug 23139 & Bug 23560
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
2015-11-13 18:47:49 +08:00
|
|
|
// We can't go further from the frame returned by GetOneMore frame. Lets try
|
2018-05-01 00:49:04 +08:00
|
|
|
// to get a different frame with using the fallback unwind plan.
|
2015-07-06 17:24:20 +08:00
|
|
|
if (!m_frames[m_frames.size() - 2]
|
Fix to solve Bug 23139 & Bug 23560
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
2015-11-13 18:47:49 +08:00
|
|
|
->reg_ctx_lldb_sp->TryFallbackUnwindPlan()) {
|
|
|
|
// We don't have a valid fallback unwind plan. Accept the frame as it is.
|
2018-05-01 00:49:04 +08:00
|
|
|
// This is a valid situation when we are at the bottom of the stack.
|
2015-07-06 17:24:20 +08:00
|
|
|
return true;
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
|
2015-07-06 17:24:20 +08:00
|
|
|
// Remove the possibly incorrect frame from the frame list and try to add a
|
2018-05-01 00:49:04 +08:00
|
|
|
// different one with the newly selected fallback unwind plan.
|
2015-07-06 17:24:20 +08:00
|
|
|
m_frames.pop_back();
|
|
|
|
CursorSP new_frame_v2 = GetOneMoreFrame(abi);
|
Fix to solve Bug 23139 & Bug 23560
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
2015-11-13 18:47:49 +08:00
|
|
|
if (new_frame_v2 == nullptr) {
|
|
|
|
// We haven't got a new frame from the fallback unwind plan. Accept the
|
2018-05-01 00:49:04 +08:00
|
|
|
// frame from the original unwind plan. This is a valid situation when we
|
|
|
|
// are at the bottom of the stack.
|
2015-07-06 17:24:20 +08:00
|
|
|
m_frames.push_back(new_frame);
|
|
|
|
return true;
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
|
2015-07-06 17:24:20 +08:00
|
|
|
// Push the new frame to the list and try to continue from this frame. If we
|
2018-05-01 00:49:04 +08:00
|
|
|
// can get a new frame then accept it as the correct one.
|
2015-07-06 17:24:20 +08:00
|
|
|
m_frames.push_back(new_frame_v2);
|
|
|
|
m_candidate_frame = GetOneMoreFrame(abi);
|
|
|
|
if (m_candidate_frame) {
|
Fix to solve Bug 23139 & Bug 23560
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
2015-11-13 18:47:49 +08:00
|
|
|
// If control reached here then TryFallbackUnwindPlan had succeeded for
|
2018-05-01 00:49:04 +08:00
|
|
|
// Cursor::m_frames[m_frames.size() - 2]. It also succeeded to Unwind next
|
|
|
|
// 2 frames i.e. m_frames[m_frames.size() - 1] and a frame after that. For
|
|
|
|
// Cursor::m_frames[m_frames.size() - 2], reg_ctx_lldb_sp field was already
|
|
|
|
// updated during TryFallbackUnwindPlan call above. However, cfa field
|
|
|
|
// still needs to be updated. Hence updating it here and then returning.
|
2018-12-15 08:15:33 +08:00
|
|
|
return m_frames[m_frames.size() - 2]->reg_ctx_lldb_sp->GetCFA(
|
|
|
|
m_frames[m_frames.size() - 2]->cfa);
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
|
2012-10-26 14:08:58 +08:00
|
|
|
// The new frame hasn't helped in unwinding. Fall back to the original one as
|
2018-05-01 00:49:04 +08:00
|
|
|
// the default unwind plan is usually more reliable then the fallback one.
|
2015-07-06 17:24:20 +08:00
|
|
|
m_frames.pop_back();
|
|
|
|
m_frames.push_back(new_frame);
|
|
|
|
return true;
|
2010-10-25 19:12:07 +08:00
|
|
|
}
|
|
|
|
|
2019-08-03 00:53:42 +08:00
|
|
|
bool UnwindLLDB::DoGetFrameInfoAtIndex(uint32_t idx, addr_t &cfa, addr_t &pc,
|
|
|
|
bool &behaves_like_zeroth_frame) {
|
2010-10-25 19:12:07 +08:00
|
|
|
if (m_frames.size() == 0) {
|
2010-11-09 10:31:21 +08:00
|
|
|
if (!AddFirstFrame())
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2012-02-21 08:09:25 +08:00
|
|
|
ProcessSP process_sp(m_thread.GetProcess());
|
[lldb] NFC modernize codebase with modernize-use-nullptr
Summary:
NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]
This commit is the result of modernizing the LLDB codebase by using
`nullptr` instread of `0` or `NULL`. See
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html
for more information.
This is the command I ran and I to fix and format the code base:
```
run-clang-tidy.py \
-header-filter='.*' \
-checks='-*,modernize-use-nullptr' \
-fix ~/dev/llvm-project/lldb/.* \
-format \
-style LLVM \
-p ~/llvm-builds/debug-ninja-gcc
```
NOTE: There were also changes to `llvm/utils/unittest` but I did not
include them because I felt that maybe this library shall be updated in
isolation somehow.
NOTE: I know this is a rather large commit but it is a nobrainer in most
parts.
Reviewers: martong, espindola, shafik, #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D61847
llvm-svn: 361484
2019-05-23 19:14:47 +08:00
|
|
|
ABI *abi = process_sp ? process_sp->GetABI().get() : nullptr;
|
2011-05-25 07:06:02 +08:00
|
|
|
|
|
|
|
while (idx >= m_frames.size() && AddOneMoreFrame(abi))
|
2010-11-09 10:31:21 +08:00
|
|
|
;
|
2010-10-25 19:12:07 +08:00
|
|
|
|
|
|
|
if (idx < m_frames.size()) {
|
2010-11-04 08:53:20 +08:00
|
|
|
cfa = m_frames[idx]->cfa;
|
|
|
|
pc = m_frames[idx]->start_pc;
|
2019-08-03 00:53:42 +08:00
|
|
|
if (idx == 0) {
|
|
|
|
// Frame zero always behaves like it.
|
|
|
|
behaves_like_zeroth_frame = true;
|
|
|
|
} else if (m_frames[idx - 1]->reg_ctx_lldb_sp->IsTrapHandlerFrame()) {
|
|
|
|
// This could be an asynchronous signal, thus the
|
|
|
|
// pc might point to the interrupted instruction rather
|
|
|
|
// than a post-call instruction
|
|
|
|
behaves_like_zeroth_frame = true;
|
|
|
|
} else if (m_frames[idx]->reg_ctx_lldb_sp->IsTrapHandlerFrame()) {
|
|
|
|
// This frame may result from signal processing installing
|
|
|
|
// a pointer to the first byte of a signal-return trampoline
|
|
|
|
// in the return address slot of the frame below, so this
|
|
|
|
// too behaves like the zeroth frame (i.e. the pc might not
|
|
|
|
// be pointing just past a call in it)
|
|
|
|
behaves_like_zeroth_frame = true;
|
2021-03-04 11:25:30 +08:00
|
|
|
} else if (m_frames[idx]->reg_ctx_lldb_sp->BehavesLikeZerothFrame()) {
|
|
|
|
behaves_like_zeroth_frame = true;
|
2019-08-03 00:53:42 +08:00
|
|
|
} else {
|
|
|
|
behaves_like_zeroth_frame = false;
|
|
|
|
}
|
2010-10-25 19:12:07 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2011-01-07 06:15:06 +08:00
|
|
|
lldb::RegisterContextSP
|
2013-11-04 17:33:30 +08:00
|
|
|
UnwindLLDB::DoCreateRegisterContextForFrame(StackFrame *frame) {
|
2011-01-07 06:15:06 +08:00
|
|
|
lldb::RegisterContextSP reg_ctx_sp;
|
2011-01-08 09:53:06 +08:00
|
|
|
uint32_t idx = frame->GetConcreteFrameIndex();
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2010-10-25 19:12:07 +08:00
|
|
|
if (idx == 0) {
|
|
|
|
return m_thread.GetRegisterContext();
|
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2010-11-09 10:31:21 +08:00
|
|
|
if (m_frames.size() == 0) {
|
|
|
|
if (!AddFirstFrame())
|
2011-01-07 06:15:06 +08:00
|
|
|
return reg_ctx_sp;
|
2010-11-09 10:31:21 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-02-21 08:09:25 +08:00
|
|
|
ProcessSP process_sp(m_thread.GetProcess());
|
[lldb] NFC modernize codebase with modernize-use-nullptr
Summary:
NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]
This commit is the result of modernizing the LLDB codebase by using
`nullptr` instread of `0` or `NULL`. See
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html
for more information.
This is the command I ran and I to fix and format the code base:
```
run-clang-tidy.py \
-header-filter='.*' \
-checks='-*,modernize-use-nullptr' \
-fix ~/dev/llvm-project/lldb/.* \
-format \
-style LLVM \
-p ~/llvm-builds/debug-ninja-gcc
```
NOTE: There were also changes to `llvm/utils/unittest` but I did not
include them because I felt that maybe this library shall be updated in
isolation somehow.
NOTE: I know this is a rather large commit but it is a nobrainer in most
parts.
Reviewers: martong, espindola, shafik, #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D61847
llvm-svn: 361484
2019-05-23 19:14:47 +08:00
|
|
|
ABI *abi = process_sp ? process_sp->GetABI().get() : nullptr;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-01-30 04:56:30 +08:00
|
|
|
while (idx >= m_frames.size()) {
|
|
|
|
if (!AddOneMoreFrame(abi))
|
|
|
|
break;
|
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-01-30 04:56:30 +08:00
|
|
|
const uint32_t num_frames = m_frames.size();
|
|
|
|
if (idx < num_frames) {
|
|
|
|
Cursor *frame_cursor = m_frames[idx].get();
|
2012-02-24 09:59:29 +08:00
|
|
|
reg_ctx_sp = frame_cursor->reg_ctx_lldb_sp;
|
2012-01-30 04:56:30 +08:00
|
|
|
}
|
2011-01-07 06:15:06 +08:00
|
|
|
return reg_ctx_sp;
|
2010-10-25 19:12:07 +08:00
|
|
|
}
|
2011-11-01 11:21:25 +08:00
|
|
|
|
2012-01-30 04:56:30 +08:00
|
|
|
UnwindLLDB::RegisterContextLLDBSP
|
2011-11-01 11:21:25 +08:00
|
|
|
UnwindLLDB::GetRegisterContextForFrameNum(uint32_t frame_num) {
|
2012-01-30 04:56:30 +08:00
|
|
|
RegisterContextLLDBSP reg_ctx_sp;
|
|
|
|
if (frame_num < m_frames.size())
|
|
|
|
reg_ctx_sp = m_frames[frame_num]->reg_ctx_lldb_sp;
|
2011-11-01 11:21:25 +08:00
|
|
|
return reg_ctx_sp;
|
|
|
|
}
|
|
|
|
|
2013-06-05 08:12:50 +08:00
|
|
|
bool UnwindLLDB::SearchForSavedLocationForRegister(
|
|
|
|
uint32_t lldb_regnum, lldb_private::UnwindLLDB::RegisterLocation ®loc,
|
2011-11-01 11:21:25 +08:00
|
|
|
uint32_t starting_frame_num, bool pc_reg) {
|
2012-11-16 09:03:31 +08:00
|
|
|
int64_t frame_num = starting_frame_num;
|
|
|
|
if (static_cast<size_t>(frame_num) >= m_frames.size())
|
2014-12-10 06:28:10 +08:00
|
|
|
return false;
|
|
|
|
|
2018-05-01 00:49:04 +08:00
|
|
|
// Never interrogate more than one level while looking for the saved pc
|
|
|
|
// value. If the value isn't saved by frame_num, none of the frames lower on
|
|
|
|
// the stack will have a useful value.
|
2013-01-19 11:53:42 +08:00
|
|
|
if (pc_reg) {
|
|
|
|
UnwindLLDB::RegisterSearchResult result;
|
|
|
|
result = m_frames[frame_num]->reg_ctx_lldb_sp->SavedLocationForRegister(
|
|
|
|
lldb_regnum, regloc);
|
2018-12-15 08:15:33 +08:00
|
|
|
return result == UnwindLLDB::RegisterSearchResult::eRegisterFound;
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2013-01-19 11:53:42 +08:00
|
|
|
while (frame_num >= 0) {
|
|
|
|
UnwindLLDB::RegisterSearchResult result;
|
|
|
|
result = m_frames[frame_num]->reg_ctx_lldb_sp->SavedLocationForRegister(
|
|
|
|
lldb_regnum, regloc);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2013-01-19 11:53:42 +08:00
|
|
|
// We descended down to the live register context aka stack frame 0 and are
|
2018-05-01 00:49:04 +08:00
|
|
|
// reading the value out of a live register.
|
2013-01-19 11:53:42 +08:00
|
|
|
if (result == UnwindLLDB::RegisterSearchResult::eRegisterFound &&
|
|
|
|
regloc.type ==
|
|
|
|
UnwindLLDB::RegisterLocation::eRegisterInLiveRegisterContext) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2014-02-21 13:20:25 +08:00
|
|
|
// If we have unwind instructions saying that register N is saved in
|
2018-05-01 00:49:04 +08:00
|
|
|
// register M in the middle of the stack (and N can equal M here, meaning
|
|
|
|
// the register was not used in this function), then change the register
|
|
|
|
// number we're looking for to M and keep looking for a concrete location
|
2014-12-10 06:28:10 +08:00
|
|
|
// down the stack, or an actual value from a live RegisterContext at frame
|
2016-09-07 04:57:50 +08:00
|
|
|
// 0.
|
2012-11-16 09:03:31 +08:00
|
|
|
if (result == UnwindLLDB::RegisterSearchResult::eRegisterFound &&
|
|
|
|
regloc.type == UnwindLLDB::RegisterLocation::eRegisterInRegister &&
|
|
|
|
frame_num > 0) {
|
|
|
|
result = UnwindLLDB::RegisterSearchResult::eRegisterNotFound;
|
2011-11-01 11:21:25 +08:00
|
|
|
lldb_regnum = regloc.location.register_number;
|
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-11-16 09:03:31 +08:00
|
|
|
if (result == UnwindLLDB::RegisterSearchResult::eRegisterFound)
|
2011-11-01 11:21:25 +08:00
|
|
|
return true;
|
2012-11-16 09:03:31 +08:00
|
|
|
if (result == UnwindLLDB::RegisterSearchResult::eRegisterIsVolatile)
|
2011-11-01 11:21:25 +08:00
|
|
|
return false;
|
|
|
|
frame_num--;
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2012-11-16 09:03:31 +08:00
|
|
|
return false;
|
2011-11-01 11:21:25 +08:00
|
|
|
}
|