[Lldb-commits] [PATCH] D39681: Implement core dump debugging for PPC64le

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

I'm not sure what's the problem with backtracing without more info, but the nice thing about core files is that you can open a ppc and x86 one side by side and see how for do you get before things start to diverge. The interesting commands you can start with are "image lookup" (to see if you can find symbols properly), "image show-unwind" (to see the unwind plans) and "log enable lldb unwind && bt" (to see backtracing in action). This is what I get for the x86_64 core file (you should be able to see the same thing yourself):

  (lldb) bt
  * thread #1, name = 'a.out', stop reason = signal SIGSEGV
    * frame #0: 0x000000000040011c linux-x86_64.out`bar(boom=0x0000000000000000) at main.c:4
      frame #1: 0x0000000000400142 linux-x86_64.out`foo(boom=0x0000000000000000, boomer=(linux-x86_64.out`bar at main.c:2)) at main.c:10
      frame #2: 0x000000000040015f linux-x86_64.out`_start at main.c:16
  (lldb) image lookup -n bar
  1 match found in /usr/local/google/home/labath/ll/lldb/test/testcases/functionalities/postmortem/elf-core/linux-x86_64.out:
          Address: linux-x86_64.out[0x000000000040010c] (linux-x86_64.out..text + 0)
          Summary: linux-x86_64.out`bar at main.c:2
  (lldb) image show-unwind -n bar
  UNWIND PLANS for linux-x86_64.out`bar (start addr 0x40010c)
  
  Asynchronous (not restricted to call-sites) UnwindPlan is 'assembly insn profiling'
  Synchronous (restricted to call-sites) UnwindPlan is 'eh_frame CFI'
  Fast UnwindPlan is 'x86_64 default unwind plan'
  
  Assembly language inspection UnwindPlan:
  This UnwindPlan originally sourced from assembly insn profiling
  This UnwindPlan is sourced from the compiler: no.
  This UnwindPlan is valid at all instruction locations: yes.
  Address range of this UnwindPlan: [linux-x86_64.out..text + 0-0x0000000000000015)
  row[0]:    0: CFA=rsp +8 => rsp=CFA+0 rip=[CFA-8] 
  row[1]:    1: CFA=rsp+16 => rbp=[CFA-16] rsp=CFA+0 rip=[CFA-8] 
  row[2]:    4: CFA=rbp+16 => rbp=[CFA-16] rsp=CFA+0 rip=[CFA-8] 
  row[3]:   20: CFA=rsp +8 => rsp=CFA+0 rip=[CFA-8] 
  
  eh_frame UnwindPlan:
  This UnwindPlan originally sourced from eh_frame CFI
  This UnwindPlan is sourced from the compiler: yes.
  This UnwindPlan is valid at all instruction locations: no.
  Address range of this UnwindPlan: [linux-x86_64.out..text + 0-0x0000000000000015)
  row[0]:    0: CFA=rsp +8 => rip=[CFA-8] 
  row[1]:    1: CFA=rsp+16 => rbp=[CFA-16] rip=[CFA-8] 
  row[2]:    4: CFA=rbp+16 => rbp=[CFA-16] rip=[CFA-8] 
  row[3]:   20: CFA=rsp +8 => rbp=[CFA-16] rip=[CFA-8] 
  
  Fast UnwindPlan:
  This UnwindPlan originally sourced from x86_64 default unwind plan
  This UnwindPlan is sourced from the compiler: no.
  This UnwindPlan is valid at all instruction locations: no.
  row[0]:    0: CFA=rbp+16 => rbp=[CFA-16] rsp=CFA+0 rip=[CFA-8] 
  
  Arch default UnwindPlan:
  This UnwindPlan originally sourced from x86_64 default unwind plan
  This UnwindPlan is sourced from the compiler: no.
  This UnwindPlan is valid at all instruction locations: no.
  row[0]:    0: CFA=rbp+16 => rbp=[CFA-16] rsp=CFA+0 rip=[CFA-8] 
  
  Arch default at entry point UnwindPlan:
  This UnwindPlan originally sourced from x86_64 at-func-entry default
  This UnwindPlan is sourced from the compiler: no.
  This UnwindPlan is valid at all instruction locations: not specified.
  row[0]:    0: CFA=rsp +8 => rsp=CFA+0 rip=[CFA-8] 



================
Comment at: source/Plugins/Process/elf-core/ProcessElfCore.cpp:659
+          thread_data->regsets.insert(
+            std::make_pair(0, DataExtractor(note_data, header_size, len)));
+
----------------
I don't think we should make up new constants for the map indices, when we already have the NT_*** constants. You just need to move the constants to a header, so that you can use them from other files. The general purpose registers are the only ones that don't have a special constant, but we can probably agree to use NT_PRSTATUS for this, as that's where we're plucking them from anyway.


================
Comment at: source/Plugins/Process/elf-core/ProcessElfCore.cpp:718
+      case NT_PPC_VMX:
+        if (arch.GetCore() == ArchSpec::eCore_ppc64le_generic)
+          thread_data->regsets.insert(std::make_pair(2, note_data));
----------------
The good thing about these maps is that you don't have to check for the architecture here. You can just store this unconditionally there, and leave it up to the consumer to decide if he wants to make use of it.


================
Comment at: source/Plugins/Process/elf-core/RegisterContextPOSIXCore_ppc64le.h:26
+      lldb_private::RegisterInfoInterface *register_info,
+      llvm::DenseMap<uint32_t, lldb_private::DataExtractor> regsets);
+
----------------
The DenseMap isn't exactly cheap to copy. You should probably pass a (constant) reference here.


https://reviews.llvm.org/D39681