[patch] Support core files with 0 < p_filesz < p_memsz (build-id)

[patch] Support core files with 0 < p_filesz < p_memsz (build-id)

[Jan Kratochvil]

[-- Attachment #1: Type: text/plain, Size: 2868 bytes --]

Hi,

there is now a pending patch for Linux kernels producing core files with the
first page of the ELF file for the build-id note identification (to find the
original versions/builds of the binaries used to produce the core file).

So far GDB handled either p_filesz == 0 or p_filesz == p_memsz.  Patch handles
the case 0 < p_filesz < p_memsz (p_filesz == PAGE_SIZE for the build-id case).

`0 < p_filesz < p_memsz' meaning was so far undefined for the ET_CORE files.

(Testsuite run verified.)

The IMO more appropriate patch for BFD to flag the p_filesz..p_memsz part the
same way as the former (0==p_filesz)..(p_memsz) core part has been rejected:
	http://sourceware.org/ml/binutils/2007-08/msg00013.html
Referencing former BFD patch (where no GDB modifications were needed):
	http://sourceware.org/ml/binutils/2007-07/msg00520.html


Regards,
Jan


New build-id enhanced Linux kernels produce core files:
Program Headers:
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
  NOTE           0x000660 0x0000000000000000 0x0000000000000000 0x000324 0x000000     0x0
  LOAD           0x001000 0x0000000000400000 0x0000000000000000 0x001000 0x0b1000 R E 0x1000
                                                                ^^^^^^^^ ^^^^^^^^
  LOAD           0x002000 0x00000000006b1000 0x0000000000000000 0x00a000 0x00a000 RW  0x1000

        GDB-patched gdb `info files'
                0x0000000000400000 - 0x0000000000401000 is load1a
                0x00000000006b1000 - 0x00000000006bb000 is load2
        0x0000000000419f00 <main+0>:    push   %r15
        0x0000000000419f02 <main+2>:    push   %r14

        BROKEN: original gdb `info files' (it sees the code sections zeroed)
                0x0000000000400000 - 0x0000000000401000 is load1a
                0x0000000000401000 - 0x00000000004b1000 is load1b
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                0x00000000006b1000 - 0x00000000006bb000 is load2
        0x0000000000419f00 <main+0>:    add    %al,(%rax)
        0x0000000000419f02 <main+2>:    add    %al,(%rax)
        (as 0x419f00 >= 0x401000)

Legacy kernel core files:
Program Headers:
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
  NOTE           0x000660 0x0000000000000000 0x0000000000000000 0x000324 0x000000     0x0
  LOAD           0x001000 0x0000000000400000 0x0000000000000000 0x000000 0x0b1000 R E 0x1000
                                                                ^^^^^^^^ ^^^^^^^^
  LOAD           0x001000 0x00000000006b1000 0x0000000000000000 0x00a000 0x00a000 RW  0x1000

        original gdb `info files'
# `load1' completely missing
                0x00000000006b1000 - 0x00000000006bb000 is load2
        0x0000000000419f00 <main+0>:    push   %r15
        0x0000000000419f02 <main+2>:    push   %r14

[-- Attachment #2: gdb-cvs-build-id-core-load.patch --]
[-- Type: text/plain, Size: 784 bytes --]

2007-08-01  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* exec.c (add_to_section_table): Ignore the BFD_CORE `loadXb' segments.

--- ./gdb/exec.c	31 Jul 2007 21:49:21 -0000	1.67
+++ ./gdb/exec.c	1 Aug 2007 14:24:51 -0000
@@ -354,6 +354,13 @@ add_to_section_table (bfd *abfd, struct 
   if (!(aflag & SEC_ALLOC))
     return;
 
+  /* Core files with 0 < p_filesz < p_memsz have the p_filesz..p_memsz section
+     without these flags.  It would be considered as .bss otherwise.  It would
+     mask out the real EXEC_BFD loaded code by its zeroes.  */
+  if (bfd_get_format (abfd) == bfd_core
+      && !(aflag & (SEC_LOAD | SEC_HAS_CONTENTS)))
+    return;
+
   (*table_pp)->bfd = abfd;
   (*table_pp)->the_bfd_section = asect;
   (*table_pp)->addr = bfd_section_vma (abfd, asect);

Re: [patch] Support core files with 0 < p_filesz < p_memsz (build-id)

[Daniel Jacobowitz]

On Wed, Aug 01, 2007 at 06:22:02PM +0200, Jan Kratochvil wrote:
> The IMO more appropriate patch for BFD to flag the p_filesz..p_memsz part the
> same way as the former (0==p_filesz)..(p_memsz) core part has been rejected:
> 	http://sourceware.org/ml/binutils/2007-08/msg00013.html
> Referencing former BFD patch (where no GDB modifications were needed):
> 	http://sourceware.org/ml/binutils/2007-07/msg00520.html

I'm going to follow up with Alan about this... I don't know what the
right BFD behavior is, but I don't believe it can be the current one.

-- 
Daniel Jacobowitz
CodeSourcery