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@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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
