[Lldb-commits] [PATCH] D31280: [LLDB][MIPS] Fix Core file Architecture and OS information

[Nitesh Jain via Phabricator via lldb-commits]

nitesh.jain added inline comments.


================
Comment at: source/Plugins/Process/elf-core/ProcessElfCore.cpp:675
+      llvm::Triple host_triple(llvm::sys::getDefaultTargetTriple());
+      target_arch.GetTriple().setOS(host_triple.getOS());
+    }
----------------
labath wrote:
> nitesh.jain wrote:
> > labath wrote:
> > > I'm not terribly happy with the default-to-host mode here, particularly as we already have some code which detects linux in ObjectFileELF::RefineModuleDetailsFromNote. I'm not terribly happy about that either, but I hope we could at least have just one dodgy detection code.
> > > 
> > > Did you check whether it's possible to extend that function to cover mips as well (probably the NT_FILE part, which searches for some `i386-linux-gnu` paths in the binary) ?
> > In our case , files path doesn't contain any Linux string. 
> > 
> > nin at debian-co3-1:~/LLVM-new/llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/postmortem/elf-core$ readelf -a linux-mips64el-gnuabi64.core
> > ELF Header:
> >   Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
> >   Class:                             ELF64
> >   Data:                              2's complement, little endian
> >   Version:                           1 (current)
> >   OS/ABI:                            UNIX - System V
> >   ABI Version:                       0
> >   Type:                              CORE (Core file)
> >   Machine:                           MIPS R3000
> >   Version:                           0x1
> >   Entry point address:               0x0
> >   Start of program headers:          64 (bytes into file)
> >   Start of section headers:          0 (bytes into file)
> >   Flags:                             0x0
> >   Size of this header:               64 (bytes)
> >   Size of program headers:           56 (bytes)
> >   Number of program headers:         6
> >   Size of section headers:           0 (bytes)
> >   Number of section headers:         0
> >   Section header string table index: 0
> > 
> > There are no sections in this file.
> > 
> > There are no sections to group in this file.
> > 
> > Program Headers:
> >   Type           Offset             VirtAddr           PhysAddr
> >                  FileSiz            MemSiz              Flags  Align
> >   NOTE           0x0000000000000190 0x0000000000000000 0x0000000000000000
> >                  0x0000000000000644 0x0000000000000000         0x0
> >   LOAD           0x0000000000001000 0x0000000120000000 0x0000000000000000
> >                  0x0000000000001000 0x0000000000001000  R E    0x1000
> >   LOAD           0x0000000000002000 0x000000fff2a60000 0x0000000000000000
> >                  0x0000000000001000 0x0000000000001000  R      0x1000
> >   LOAD           0x0000000000003000 0x000000fff2a61000 0x0000000000000000
> >                  0x0000000000001000 0x0000000000001000  R E    0x1000
> >   LOAD           0x0000000000004000 0x000000ffffc01000 0x0000000000000000
> >                  0x0000000000002000 0x0000000000002000  RWE    0x1000
> >   LOAD           0x0000000000006000 0x000000fffffff000 0x0000000000000000
> >                  0x0000000000000000 0x0000000000001000  RWE    0x1000
> > 
> > There is no dynamic section in this file.
> > 
> > There are no relocations in this file.
> > 
> > The decoding of unwind sections for machine type MIPS R3000 is not currently supported.
> > 
> > Dynamic symbol information is not available for displaying symbols.
> > 
> > No version information found in this file.
> > 
> > Displaying notes found at file offset 0x00000190 with length 0x00000644:
> >   Owner                 Data size       Description
> >   CORE                 0x000001e0       NT_PRSTATUS (prstatus structure)
> >   CORE                 0x00000088       NT_PRPSINFO (prpsinfo structure)
> >   CORE                 0x00000080       NT_SIGINFO (siginfo_t data)
> >   CORE                 0x00000130       NT_AUXV (auxiliary vector)
> >   CORE                 0x000000aa       NT_FILE (mapped files)
> >     Page size: 4096
> >                  Start                 End         Page Offset
> >     0x0000000120000000  0x0000000120001000  0x0000000000000000
> >         /home/nin/LLVM-new/llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/postmortem/elf-core/linux-mips64el-gnuabi64.out
> > 
> That's a good point. In fact that is the case on the x86 core files as well we have checked in as well, as their executables were linked statically. Only, I guess in the x86 case we don't rely on the os that much.
> 
> Will this affect the ability of the tests to run reproducibly (on windows for example), or will the os be picked up from the executable if it is present? If it won't then we'll need to think hard about how to make the tests deterministic.
If Host OS is windows then this test case will fail. The MIPS support freeBSD, Linux and Android.  The note.n_name == LLDB_NT_OWNER_GNU is valid for Linux platform. Hence we can used this information to set OS. 




Repository:
  rL LLVM

https://reviews.llvm.org/D31280