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

Tue Mar 1 08:47:34 PST 2016

Hi,

Thanks for the report. I've had my eye set on this for a while, but
unfortunately it hasn't gotten to the top of the list yet. The main
reasons i was slow to respond are:
- there is no test included.
- I am not entirely sure about the proposed solution. It looks a bit
hackish (the stop reason part) and I was hoping I could come up with a
cleaner solution...

So, for the thread id part, I'd be happy to commit that as soon as you
create a test (or you can wait until I create one at some point...).

For the stop reason, if you want to speed it up, you can try running
the patch by Jim Ingham, as he's the one who will have to approve that
anyway. (and please also add a test)

cheers,
pl

On 26 February 2016 at 16:58, Zachary Turner <zturner at google.com> wrote:
> 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