[lldb-dev] Problems with core load on Linux and proposed solution
Eugene Birukov via lldb-dev
lldb-dev at lists.llvm.org
Thu Feb 25 17:17:59 PST 2016
No response. I filed a bug, hopefully somebody will pay attention.
https://llvm.org/bugs/show_bug.cgi?id=26322
From: mikem at microsoft.com
To: eugenebi at hotmail.com; lldb-dev at lists.llvm.org
Subject: RE: Problems with core load on Linux and proposed solution
Date: Thu, 25 Feb 2016 22:37:45 +0000
Eugene, do you know if they have taken these changes? Have you heard from anybody on lldb-dev?
mikem
From: Eugene Birukov [mailto:eugenebi at hotmail.com]
Sent: Thursday, January 21, 2016 10:46 AM
To: LLDB <lldb-dev at lists.llvm.org>
Subject: Problems with core load on Linux and proposed solution
Hi,
LLDB 3.8 has much better support for core load on Linux than 3.7 - thanks a lot! But there are still two problems.
1. The thread ID are lost and there is FIXME in the code
2. If core dump is obtained from live process (i.e. gdb attach, gcore, detach) then there is no thread that has any reason to stop. LLDB hangs forever on such a core.
Here is the fix that works for me for both problems.
Thanks,
Eugene
diff --git a/include/lldb/Target/Process.h b/include/lldb/Target/Process.h
index 6bb7a3d..915ca15 100644
--- a/include/lldb/Target/Process.h
+++ b/include/lldb/Target/Process.h
@@ -3401,6 +3401,7 @@ protected:
std::map<lldb::addr_t,lldb::addr_t> m_resolved_indirect_addresses;
bool m_destroy_in_process;
bool m_can_interpret_function_calls; // Some targets, e.g the OSX kernel, don't support the ability to modify the stack.
+ bool m_load_core; // True if we are looking at a core dump, not at a running program
WarningsCollection m_warnings_issued; // A set of object pointers which have already had warnings printed
enum {
diff --git a/source/Plugins/Process/elf-core/ProcessElfCore.cpp b/source/Plugins/Process/elf-core/ProcessElfCore.cpp
index 5b5d98a..fa057f1 100644
--- a/source/Plugins/Process/elf-core/ProcessElfCore.cpp
+++ b/source/Plugins/Process/elf-core/ProcessElfCore.cpp
@@ -559,11 +559,10 @@ ProcessElfCore::ParseThreadContextsFromNoteSegment(const elf::ELFProgramHeader *
have_prstatus = true;
prstatus.Parse(note_data, arch);
thread_data->signo = prstatus.pr_cursig;
+ thread_data->tid = prstatus.pr_pid;
header_size = ELFLinuxPrStatus::GetSize(arch);
len = note_data.GetByteSize() - header_size;
thread_data->gpregset = DataExtractor(note_data, header_size, len);
- // FIXME: Obtain actual tid on Linux
- thread_data->tid = m_thread_data.size();
break;
case NT_FPREGSET:
thread_data->fpregset = note_data;
diff --git a/source/Target/Process.cpp b/source/Target/Process.cpp
index e4fe419..489b307 100644
--- a/source/Target/Process.cpp
+++ b/source/Target/Process.cpp
@@ -767,6 +767,7 @@ Process::Process(lldb::TargetSP target_sp, Listener &listener, const UnixSignals
m_last_broadcast_state (eStateInvalid),
m_destroy_in_process (false),
m_can_interpret_function_calls(false),
+ m_load_core(false),
m_warnings_issued (),
m_can_jit(eCanJITDontKnow)
{
@@ -3088,6 +3089,7 @@ Process::LoadCore ()
// We successfully loaded a core file, now pretend we stopped so we can
// show all of the threads in the core file and explore the crashed
// state.
+ m_load_core = true;
SetPrivateState (eStateStopped);
// Wait indefinitely for a stopped event since we just posted one above...
@@ -3975,6 +3977,11 @@ Process::ShouldBroadcastEvent (Event *event_ptr)
if (!was_restarted)
should_resume = m_thread_list.ShouldStop (event_ptr) == false;
+
+ // ShouldStop() above has some side effects besides calculating return value,
+ // so we better not skip it. But if we are loading core we should not resume.
+ if (m_load_core)
+ should_resume = false;
if (was_restarted || should_resume || m_resume_requested)
{
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160225/de854b87/attachment-0001.html>
More information about the lldb-dev
mailing list