Re: [patch] bfd: Core files with p_filesz < p_memsz (build-id)

[Daniel Jacobowitz <drow at false dot org>]

On Wed, Aug 01, 2007 at 10:35:47PM +0930, Alan Modra wrote:
> On Sun, Jul 29, 2007 at 06:53:15PM +0200, Jan Kratochvil wrote:
> > On Sat, 28 Jul 2007 22:16:04 +0200, Roland McGrath wrote:
> > > Are you sure that changing _bfd_elf_make_section_from_phdr is the right way
> > > to fix gdb?
> > > 
> > > It is in a certain sense accurate to split the one segment into two
> > > sections, a leading SEC_LOAD one and a trailing one without SEC_LOAD.
> > 
> > The core files with `p_filesz == 0' were working before.
> 
> I think BFD is still doing the right thing.  Please fix this in gdb.

Could you elaborate?  Consider a core with these headers:

  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  NOTE           0x0000000000000388 0x0000000000000000  0x0000000000000000
                 0x0000000000000314 0x0000000000000000         0
  LOAD           0x0000000000001000 0x0000000000400000  0x0000000000000000
                 0x0000000000000000 0x0000000000005000  R E    1000
  LOAD           0x0000000000001000 0x0000000000504000  0x0000000000000000
                 0x0000000000000100 0x0000000000001000  RW     1000

That's 20K at 0x400000, none of which is in the core dump, and 4K at
0x504000, 256 bytes of which is in the core dump.  A reasonably
current objdump produces these pseudo-sections:

  4 load1         00000000  0000000000400000  0000000000000000  00001000  2**12
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  5 load2a        00000100  0000000000504000  0000000000000000  00001000  2**12
                  CONTENTS, ALLOC, LOAD
  6 load2b        00000f00  0000000000504100  0000000000000100  00000000  2**0
                  ALLOC

So we report the BSS portion of an entirely BSS PT_LOAD as having size
zero (plus contents flag, bizarre).  But the BSS portion of a partially
filled PT_LOAD is shown with size equal to its memory size.  I don't
see why they should be inconsistent, and it makes handling this in GDB
a little awkward.

I don't think the zero-sized fake sections have any value.  Certainly
GDB just skips over them when it's walking its tables.  That suggests
we don't need either load1 or load2b.  Obviously we could make a more
faithful representation of the program headers; that will make an
unmodified GDB start reading zeros from undumped segments though.

-- 
Daniel Jacobowitz
CodeSourcery