https://llvm.org/bugs/show_bug.cgi?id=30485
Bug ID: 30485 Summary: lldb assertion "Architecture or OS not supported" when loading Ubuntu core dump Product: lldb Version: 3.9 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: richard_chamberl...@uk.ibm.com CC: llvm-b...@lists.llvm.org Classification: Unclassified Error and log messages: elf-core::CreateRegisterContextForFrame:: Architecture(27) or OS(0) not supported lldb: /home/rchamberlain/lldb/llvm/tools/lldb/source/Plugins/Process/elf-core/ThreadElfCore.cpp:146: virtual lldb::RegisterContextSP ThreadElfCore::CreateRegisterContextForFrame(lldb_private::StackFrame*): Assertion `false && "Architecture or OS not supported"' failed. Problen seen on lldb trunk version 4.0.0 (http://llvm.org/svn/llvm-project/lldb/trunk revision 281963 clang revision 281963 llvm revision 281963). Also fails on lldb 3.9.0. The core dump was produced by an Ubuntu 14.04 instance (OS version: Linux 3.19.0-33-generic #38~14.04.1-Ubuntu SMP Fri Nov 6 18:17:28 UTC 2015) running in IBM Bluemix/Cloud Foundry. Core dumps from Ubuntu running 'on the metal' work fine. The difference seems to be that the library paths in the ELF notes section that lldb uses to identify the core dump as Linux have an additional prefix in the failing case. So the check for a path that starts with /lib/x86_64-linux-gnu does not work for these core dumps. Relevant lldb code is here: Plugins/ObjectFile/ELF/ObjectFileELF.cpp ObjectFileELF::RefineModuleDetailsFromNote() llvm::StringRef path(cstr); if (path.startswith("/lib/x86_64-linux-gnu") || path.startswith("/lib/i386-linux-gnu")) { arch_spec.GetTriple().setOS(llvm::Triple::OSType::Linux); Notes section in core dump: ~/test$ readelf -n core-node-6-100-1470315046 Displaying notes found at file offset 0x000023b0 with length 0x00003d14: Owner Data size Description CORE 0x00000150 NT_PRSTATUS (prstatus structure) CORE 0x00000088 NT_PRPSINFO (prpsinfo structure) CORE 0x00000080 NT_SIGINFO (siginfo_t data) CORE 0x00000130 NT_AUXV (auxiliary vector) CORE 0x000017db NT_FILE (mapped files) Page size: 4096 Start End Page Offset 0x0000000000400000 0x00000000017bc000 0x0000000000000000 /warden/depot/19p5hmkqpps/tmp/rootfs/home/vcap/app/vendor/node/bin/node 0x00000000019bc000 0x00000000019d5000 0x00000000000013bc .... /packages/rootfs_cflinuxfs2/..../lib/x86_64-linux-gnu/libc-2.19.so 0x00007fbe4a139000 0x00007fbe4a339000 0x00000000000001ba /packages/rootfs_cflinuxfs2/..../rootfs/lib/x86_64-linux-gnu/libc-2.19.so 0x00007fbe4a339000 0x00007fbe4a33d000 0x00000000000001ba /packages/rootfs_cflinuxfs2/..../rootfs/lib/x86_64-linux-gnu/libc-2.19.so 0x00007fbe4a33d000 0x00007fbe4a33f000 0x00000000000001be .... Suggested fix would be to widen the test slightly, e.g. path.find("/lib/x86_64-linux-gnu") rather than path.startswith("/lib/x86_64-linux-gnu") This solution was already hinted at by Ted Woodward here: http://lists.llvm.org/pipermail/lldb-dev/2016-August/010974.html Offending core dump(s) available on request. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev