)]}'
{
  "commit": "087969169836f802a09b1cd0502d2f22d7a8f7dc",
  "tree": "f2287250a856f3717a047e03af2347c1130126b4",
  "parents": [
    "8bcead69665af3a9f9867cd34c3a1daf22120027"
  ],
  "author": {
    "name": "Andrew Burgess",
    "email": "aburgess@redhat.com",
    "time": "Tue May 23 11:25:21 2023 +0100"
  },
  "committer": {
    "name": "Andrew Burgess",
    "email": "aburgess@redhat.com",
    "time": "Mon Jul 03 18:02:26 2023 +0100"
  },
  "message": "gdb: handle core files with .reg/0 section names\n\nThe previous commit added the test gdb.arch/core-file-pid0.exp which\ntests GDB\u0027s ability to load a core file containing threads with an\nlwpid of 0, which is something we GDB can encounter when loading a\nvmcore file -- a core file generated by the Linux kernel.  The threads\nwith an lwpid of 0 represents idle cores.\n\nWhile the previous commit added the test, which confirms GDB doesn\u0027t\ncrash when confronted with such a core file, there are still some\nproblems with GDB\u0027s handling of these core files.  These problems all\noriginate from the fact that the core file (once opened by bfd)\ncontains multiple sections called .reg/0, these sections all\nrepresents different threads (cpu cores in the original vmcore dump),\nbut GDB gets confused and thinks all of these .reg/0 sections are all\nreferencing the same thread.\n\nHere is a GDB session on an x86-64 machine which loads the core file\nfrom the gdb.arch/core-file-pid0.exp, this core file contains two\nthreads, both of which have a pid of 0:\n\n  $ ./gdb/gdb --data-directory ./gdb/data-directory/ -q\n  (gdb) core-file /tmp/x86_64-pid0-core.core\n  [New process 1]\n  [New process 1]\n  Failed to read a valid object file image from memory.\n  Core was generated by `./segv-mt\u0027.\n  Program terminated with signal SIGSEGV, Segmentation fault.\n  The current thread has terminated\n  (gdb) info threads\n    Id   Target Id         Frame\n    2    process 1         0x00000000004017c2 in ?? ()\n\n  The current thread \u003cThread ID 1\u003e has terminated.  See `help thread\u0027.\n  (gdb) maintenance info sections\n  Core file: `/tmp/x86_64-pid0-core.core\u0027, file type elf64-x86-64.\n   [0]      0x00000000-\u003e0x000012d4 at 0x00000318: note0 READONLY HAS_CONTENTS\n   [1]      0x00000000-\u003e0x000000d8 at 0x0000039c: .reg/0 HAS_CONTENTS\n   [2]      0x00000000-\u003e0x000000d8 at 0x0000039c: .reg HAS_CONTENTS\n   [3]      0x00000000-\u003e0x00000080 at 0x0000052c: .note.linuxcore.siginfo/0 HAS_CONTENTS\n   [4]      0x00000000-\u003e0x00000080 at 0x0000052c: .note.linuxcore.siginfo HAS_CONTENTS\n   [5]      0x00000000-\u003e0x00000140 at 0x000005c0: .auxv HAS_CONTENTS\n   [6]      0x00000000-\u003e0x000000a4 at 0x00000714: .note.linuxcore.file/0 HAS_CONTENTS\n   [7]      0x00000000-\u003e0x000000a4 at 0x00000714: .note.linuxcore.file HAS_CONTENTS\n   [8]      0x00000000-\u003e0x00000200 at 0x000007cc: .reg2/0 HAS_CONTENTS\n   [9]      0x00000000-\u003e0x00000200 at 0x000007cc: .reg2 HAS_CONTENTS\n   [10]     0x00000000-\u003e0x00000440 at 0x000009e0: .reg-xstate/0 HAS_CONTENTS\n   [11]     0x00000000-\u003e0x00000440 at 0x000009e0: .reg-xstate HAS_CONTENTS\n   [12]     0x00000000-\u003e0x000000d8 at 0x00000ea4: .reg/0 HAS_CONTENTS\n   [13]     0x00000000-\u003e0x00000200 at 0x00000f98: .reg2/0 HAS_CONTENTS\n   [14]     0x00000000-\u003e0x00000440 at 0x000011ac: .reg-xstate/0 HAS_CONTENTS\n   [15]     0x00400000-\u003e0x00401000 at 0x00002000: load1 ALLOC LOAD READONLY HAS_CONTENTS\n   [16]     0x00401000-\u003e0x004b9000 at 0x00003000: load2 ALLOC READONLY CODE\n   [17]     0x004b9000-\u003e0x004e5000 at 0x00003000: load3 ALLOC READONLY\n   [18]     0x004e6000-\u003e0x004ec000 at 0x00003000: load4 ALLOC LOAD HAS_CONTENTS\n   [19]     0x004ec000-\u003e0x004f2000 at 0x00009000: load5 ALLOC LOAD HAS_CONTENTS\n   [20]     0x012a8000-\u003e0x012cb000 at 0x0000f000: load6 ALLOC LOAD HAS_CONTENTS\n   [21]     0x7fda77736000-\u003e0x7fda77737000 at 0x00032000: load7 ALLOC READONLY\n   [22]     0x7fda77737000-\u003e0x7fda77f37000 at 0x00032000: load8 ALLOC LOAD HAS_CONTENTS\n   [23]     0x7ffd55f65000-\u003e0x7ffd55f86000 at 0x00832000: load9 ALLOC LOAD HAS_CONTENTS\n   [24]     0x7ffd55fc3000-\u003e0x7ffd55fc7000 at 0x00853000: load10 ALLOC LOAD READONLY HAS_CONTENTS\n   [25]     0x7ffd55fc7000-\u003e0x7ffd55fc9000 at 0x00857000: load11 ALLOC LOAD READONLY CODE HAS_CONTENTS\n   [26]     0xffffffffff600000-\u003e0xffffffffff601000 at 0x00859000: load12 ALLOC LOAD READONLY CODE HAS_CONTENTS\n  (gdb)\n\nNotice when the core file is first loaded we see two lines like:\n\n  [New process 1]\n\nAnd GDB reports:\n\n  The current thread has terminated\n\nWhich isn\u0027t what we\u0027d expect from a core file -- the core file should\nonly contain threads that are live at the point of the crash, one of\nwhich should be the current thread.  The above message is reported\nbecause GDB has deleted what we think is the current thread!\n\nAnd in the \u0027info threads\u0027 output we are only seeing a single thread,\nagain, this is because GDB has deleted one of the threads.\n\nFinally, the \u0027maintenance info sections\u0027 output shows the cause of all\nour problems, two sections named .reg/0.  When GDB sees the first of\nthese it creates a new thread.  But, when we see the second .reg/0 GDB\ntries to create another new thread, but this thread has the same\nptid_t as the first thread, so GDB deletes the first thread and\ncreates the second thread in its place.\n\nBecause both these threads are created with an lwpid of 0 GDB reports\nthese are \u0027New process NN\u0027 rather than \u0027New LWP NN\u0027 which is what we\nwould normally expect.\n\nThe previous commit includes a little more of the history of GDB\nsupport in this area, but these problems were discussed on the mailing\nlist a while ago in this thread:\n\n  https://inbox.sourceware.org/gdb-patches/AANLkTi\u003dzuEDw6qiZ1jRatkdwHO99xF2Qu+WZ7i0EQjef@mail.gmail.com/\n\nIn this commit I propose a solution to these problems.\n\nWhat I propose is that GDB should spot when we have .reg/0 sections\nand, when these are found, should rename these sections using some\nunique non-zero lwpid.\n\nNote in the above output we also have sections like .reg2/0 and\n.reg-xstate/0, these are additional register sets, this commit also\nrenumbers these sections inline with their .reg section.\n\nThe user is warned that some section renumbering has been performed.\n\nGDB takes care to ensure that the new numbers assigned are unique and\ndon\u0027t clash with any of the pid\u0027s that might already be in use --\nremember, in a real vmcore file, 0 is used to indicate an idle core,\nnon-idle cores will have the pid of whichever process was running on\nthat core, so we don\u0027t want GDB to assign an lwpid that clashes with\nan actual pid that is in use in the core file.\n\nAfter this commit here\u0027s the updated GDB session output:\n\n  $ ./gdb/gdb --data-directory ./gdb/data-directory/ -q\n  (gdb) core-file /tmp/x86_64-pid0-core.core\n  warning: found threads with pid 0, assigned replacement Target Ids: LWP 1, LWP 2\n  [New LWP 1]\n  [New LWP 2]\n  Failed to read a valid object file image from memory.\n  Core was generated by `./segv-mt\u0027.\n  Program terminated with signal SIGSEGV, Segmentation fault.\n  #0  0x00000000004017c2 in ?? ()\n  [Current thread is 1 (LWP 1)]\n  (gdb) info threads\n    Id   Target Id         Frame\n  * 1    LWP 1             0x00000000004017c2 in ?? ()\n    2    LWP 2             0x000000000040dda5 in ?? ()\n  (gdb) maintenance info sections\n  Core file: `/tmp/x86_64-pid0-core.core\u0027, file type elf64-x86-64.\n   [0]      0x00000000-\u003e0x000012d4 at 0x00000318: note0 READONLY HAS_CONTENTS\n   [1]      0x00000000-\u003e0x000000d8 at 0x0000039c: .reg/1 HAS_CONTENTS\n   [2]      0x00000000-\u003e0x000000d8 at 0x0000039c: .reg HAS_CONTENTS\n   [3]      0x00000000-\u003e0x00000080 at 0x0000052c: .note.linuxcore.siginfo/1 HAS_CONTENTS\n   [4]      0x00000000-\u003e0x00000080 at 0x0000052c: .note.linuxcore.siginfo HAS_CONTENTS\n   [5]      0x00000000-\u003e0x00000140 at 0x000005c0: .auxv HAS_CONTENTS\n   [6]      0x00000000-\u003e0x000000a4 at 0x00000714: .note.linuxcore.file/1 HAS_CONTENTS\n   [7]      0x00000000-\u003e0x000000a4 at 0x00000714: .note.linuxcore.file HAS_CONTENTS\n   [8]      0x00000000-\u003e0x00000200 at 0x000007cc: .reg2/1 HAS_CONTENTS\n   [9]      0x00000000-\u003e0x00000200 at 0x000007cc: .reg2 HAS_CONTENTS\n   [10]     0x00000000-\u003e0x00000440 at 0x000009e0: .reg-xstate/1 HAS_CONTENTS\n   [11]     0x00000000-\u003e0x00000440 at 0x000009e0: .reg-xstate HAS_CONTENTS\n   [12]     0x00000000-\u003e0x000000d8 at 0x00000ea4: .reg/2 HAS_CONTENTS\n   [13]     0x00000000-\u003e0x00000200 at 0x00000f98: .reg2/2 HAS_CONTENTS\n   [14]     0x00000000-\u003e0x00000440 at 0x000011ac: .reg-xstate/2 HAS_CONTENTS\n   [15]     0x00400000-\u003e0x00401000 at 0x00002000: load1 ALLOC LOAD READONLY HAS_CONTENTS\n   [16]     0x00401000-\u003e0x004b9000 at 0x00003000: load2 ALLOC READONLY CODE\n   [17]     0x004b9000-\u003e0x004e5000 at 0x00003000: load3 ALLOC READONLY\n   [18]     0x004e6000-\u003e0x004ec000 at 0x00003000: load4 ALLOC LOAD HAS_CONTENTS\n   [19]     0x004ec000-\u003e0x004f2000 at 0x00009000: load5 ALLOC LOAD HAS_CONTENTS\n   [20]     0x012a8000-\u003e0x012cb000 at 0x0000f000: load6 ALLOC LOAD HAS_CONTENTS\n   [21]     0x7fda77736000-\u003e0x7fda77737000 at 0x00032000: load7 ALLOC READONLY\n   [22]     0x7fda77737000-\u003e0x7fda77f37000 at 0x00032000: load8 ALLOC LOAD HAS_CONTENTS\n   [23]     0x7ffd55f65000-\u003e0x7ffd55f86000 at 0x00832000: load9 ALLOC LOAD HAS_CONTENTS\n   [24]     0x7ffd55fc3000-\u003e0x7ffd55fc7000 at 0x00853000: load10 ALLOC LOAD READONLY HAS_CONTENTS\n   [25]     0x7ffd55fc7000-\u003e0x7ffd55fc9000 at 0x00857000: load11 ALLOC LOAD READONLY CODE HAS_CONTENTS\n   [26]     0xffffffffff600000-\u003e0xffffffffff601000 at 0x00859000: load12 ALLOC LOAD READONLY CODE HAS_CONTENTS\n  (gdb)\n\nNotice the new warning which is issued when the core file is being\nloaded.  The threads are announced as \u0027[New LWP NN]\u0027, and we see two\nthreads in the \u0027info threads\u0027 output.  The \u0027maintenance info sections\u0027\noutput shows the result of the section renaming.\n\nThe gdb.arch/core-file-pid0.exp test has been update to check for the\nimproved GDB output.\n\nReviewed-By: Kevin Buettner \u003ckevinb@redhat.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "e706427772ab4b8847a29119cf2a145c45f2bbc0",
      "old_mode": 33188,
      "old_path": "gdb/corelow.c",
      "new_id": "46bb1077b6d33b1a4ace7f8d283192b36a8cc26e",
      "new_mode": 33188,
      "new_path": "gdb/corelow.c"
    },
    {
      "type": "modify",
      "old_id": "b960dfe095bbd22d5aaaf41ba64a8e38acb9c1e9",
      "old_mode": 33188,
      "old_path": "gdb/testsuite/gdb.arch/core-file-pid0.exp",
      "new_id": "6e91111b44b9871bde6a138b023cc53528d4a5bc",
      "new_mode": 33188,
      "new_path": "gdb/testsuite/gdb.arch/core-file-pid0.exp"
    }
  ]
}