{"id":5367,"date":"2014-03-30T21:07:44","date_gmt":"2014-03-30T21:07:44","guid":{"rendered":"https:\/\/unknownerror.org\/index.php\/2014\/03\/30\/remote-post-mortem-coredump-analysis-without-having-exact-debug-symbols-for-shared-system-libraries-collection-of-common-programming-errors\/"},"modified":"2014-03-30T21:07:44","modified_gmt":"2014-03-30T21:07:44","slug":"remote-post-mortem-coredump-analysis-without-having-exact-debug-symbols-for-shared-system-libraries-collection-of-common-programming-errors","status":"publish","type":"post","link":"https:\/\/unknownerror.org\/index.php\/2014\/03\/30\/remote-post-mortem-coredump-analysis-without-having-exact-debug-symbols-for-shared-system-libraries-collection-of-common-programming-errors\/","title":{"rendered":"Remote Post-mortem coredump analysis without having exact debug symbols for shared system libraries-Collection of common programming errors"},"content":{"rendered":"
    \n
  1. \n

    It depends. On some processors, such as x86_64<\/code>, correct unwind descriptors are required for GDB to properly unwind the stack. On such machine, analyzing coredump with non-matching libc will likely produce complete garbage.<\/p>\n<\/li>\n

  2. \n

    You don’t need debug symbols for libc to get the stack trace. You wouldn’t get file and line numbers without debug symbols, but you should get correct function names (except when inlining has taken place).<\/p>\n<\/li>\n

  3. \n

    The premise of your question is wrong — debug symbols have nothing to do with this. The “correct” way to analyze coredump on C2, when that coredump was produced on C1, is to have a copy of C1’s libraries (in e.g. \/tmp\/C1\/lib\/...<\/code>) and direct GDB to use that copy instead of the C2’s installed libc<\/code> with<\/p>\n

    (gdb) set solib-absolute-prefix \/tmp\/C1<\/code><\/p>\n<\/li>\n<\/ol>\n

    command.<\/p>\n

    Note<\/strong>: above setting must<\/em> be in effect before you load the core into GDB. This:<\/p>\n

    gdb exe core\n(gdb) set solib-absolute-prefix \/tmp\/C1\n<\/code><\/pre>\n
    will not work (core is read before the setting is in effect).<\/p>\n
    Here is the right way:<\/p>\n
    gdb exe\n(gdb) set solib-absolute-prefix \/tmp\/C1\n(gdb) core core\n<\/code><\/pre>\n
    (I’ve tried to find a reference to this on the web, but didn’t).<\/p>\n
    What are unwind descriptors?<\/em><\/p>\n
    Unwind descriptors are required when code is compiled without frame pointers (default for x86_64 in optimized mode). Such code does not<\/em> save %rbp register, and so GDB needs to be told how to “step back” from current frame to the caller frame (this process is also known as stack unwinding).<\/p>\n
    Why isn’t C1’s libc.so included in the core?<\/em><\/p>\n
    The core file usually contains only contents of writable segments of the program address space. The read-only segments (where executable code and unwind descriptors reside) is not usually necessary — you could just read them directly from libc.so on disk.<\/p>\n
    Except this doesn’t work when you analyze C1’s core on C2!<\/p>\n
    Some (but not all) operating systems allow one to configure “full coredumps”, where the OS will dump read-only mappings as well, precisely so you can analyze core on any machine.<\/p>\n","protected":false},"excerpt":{"rendered":"
    It depends. On some processors, such as x86_64, correct unwind descriptors are required for GDB to properly unwind the stack. On such machine, analyzing coredump with non-matching libc will likely produce complete garbage. You don’t need debug symbols for libc to get the stack trace. You wouldn’t get file and line numbers without debug symbols, […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-5367","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts\/5367","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/comments?post=5367"}],"version-history":[{"count":0,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts\/5367\/revisions"}],"wp:attachment":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/media?parent=5367"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/categories?post=5367"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/tags?post=5367"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}