[lldb-dev] Problems with core load on Linux and proposed solution

Zachary Turner via lldb-dev lldb-dev at lists.llvm.org
Fri Feb 26 08:58:37 PST 2016


Cced some people who work on Linux.

Not sure how this slipped through the cracks, but sometimes you can have
better results by just posting a patch to lldb-commits and ccing the right
person (check owners file to find out who the right person is)

On Thu, Feb 25, 2016 at 5:18 PM Eugene Birukov via lldb-dev <
lldb-dev at lists.llvm.org> wrote:

> 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)
>
>                  {
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160226/a6959ed9/attachment.html>


More information about the lldb-dev mailing list