Re: Some recent change broke GDB's core writing

[Alan Modra <amodra at bigpond dot net dot au>]

<200705061903.l46J30e3031287@d12av02.megacenter.de.ibm.com>, <20070506154715.GA10675@caradoc.them.org>

On Sun, May 06, 2007 at 11:47:15AM -0400, Daniel Jacobowitz wrote:
> The GDB testsuite now reports:
> 
> gcore /space/fsf/x86-64/commit-gdb/gdb/testsuite/gdb.base/auxv.gcore
> BFD: /space/fsf/x86-64/commit-gdb/gdb/testsuite/gdb.base/auxv.gcore:
> section `note0' can't be allocated in segment 0
> warning: Failed to write corefile contents (Bad value).
> 
> Alan, I assume this was you, since you've been adjusting the
> section-in-segment logic?  It's possible that GDB is at fault, of
> course; I won't have time to dig into it until later.

My patch rashly enabled core file note section-in-segment checks.
These fail the tests because assign_file_positions_for_load_sections
sets the note segment p_memsz to zero, which leads to failing the
section VMA within segment test.

Disabling the check for notes then shows failures for load sections,
since gdb appears to twiddle the SEC_LOAD flag for its own nefarious
purposes.  SEC_LOAD clear leads to segments with wrong p_filesz, at
least according to ELF_IS_SECTION_IN_SEGMENT.

Section Headers:
  [Nr] Name          Type        Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]               NULL        00000000 000000 000000 00      0   0  0
  [ 1] note0         PROGBITS    00000000 0002d4 00046c 00   A  0   0  1
  [ 2] load          PROGBITS    08048000 000740 259000 00  AX  0   0  1
  [ 3] load          PROGBITS    082a1000 259740 00b000 00  WA  0   0  1
[snip]
Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  NOTE           0x0002d4 0x00000000 0x00000000 0x0046c 0x00000 R   0x1
  LOAD           0x000740 0x08048000 0x00000000 0x00000 0x259000 R E 0x1
  LOAD           0x259740 0x082a1000 0x00000000 0x0b000 0x0b000 RW  0x1
[snip]

I guess the intention here is to omit writing the first load section
to the core file, and you're supposed to know that the first load
section header saying that the section is PROGBITS at offset 740 is
lying.  It probably ought to be NOBITS, and we shouldn't be bumping
file offset for it, both of which we could get by removing the
SEC_HAS_CONTENTS check after the FIXME in
assign_file_positions_for_load_sections, but I'm disinclined to mess
around here.  Perhaps someone more familiar with gdb might like to try
it out.  You'd get smaller core files (especially on operating systems
that don't support files with holes).

So..  This disables section-in-segment checks for core files.

	* elf.c (assign_file_positions_for_load_sections): Don't check
	core segment.

Index: bfd/elf.c
===================================================================
RCS file: /cvs/src/src/bfd/elf.c,v
retrieving revision 1.385
diff -u -p -r1.385 elf.c
--- bfd/elf.c	2 May 2007 13:44:37 -0000	1.385
+++ bfd/elf.c	7 May 2007 00:38:40 -0000
@@ -4641,9 +4641,9 @@ assign_file_positions_for_load_sections 
 	    }
 	}
 
-      /* Check that all sections are in the segment.  */
-      if (p->p_type == PT_LOAD
-	  || (p->p_type == PT_NOTE && bfd_get_format (abfd) == bfd_core))
+      /* Check that all sections are in a PT_LOAD segment.
+	 Don't check funky gdb generated core files.  */
+      if (p->p_type == PT_LOAD && bfd_get_format (abfd) != bfd_core)
 	for (i = 0, secpp = m->sections; i < m->count; i++, secpp++)
 	  {
 	    Elf_Internal_Shdr *this_hdr;

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre