core grokking bug, RHBZ#484623

[Roland McGrath <roland at redhat dot com>]

Brain dump wrt https://bugzilla.redhat.com/show_bug.cgi?id=484623
It is minor but can be fixed with some thought.
Dumping brain state since I won't get to it right now.

I removed (45c01cd4) the assert, since it was depending on a confluence of
guesses never producing anomalies.  But the underlying cause is just masked
(well, shown in anomalous output) now and still should be fixed.

Case is a core file without partial-segments dumps, so using:
	unstrip -n -e exec --core core

Relevant core phdrs:

  LOAD           0x001000 0x0000000000400000 0x0000000000000000 0x000000 0x001000 R E 0x1000
  LOAD           0x001000 0x0000000000600000 0x0000000000000000 0x001000 0x001000 RW  0x1000

Those are from the tiny binary:

  LOAD           0x000000 0x0000000000400000 0x0000000000400000 0x000904 0x000904 R E 0x200000
  LOAD           0x000908 0x0000000000600908 0x0000000000600908 0x000224 0x000240 RW  0x200000

This one is ET_EXEC so we could be jiggering differently by assuming
absolute addresses.  The dwfl_segment_report_module logic treats ET_EXEC
and ET_DYN the same in its guesstimation.  I think it's good to keep that
because a) a tiny DSO would have the same issue as this case and b)
an ET_EXEC in an image might be an odd use like a Linux kernel (in a vmcore),
which is effectively ET_DYN sometimes (i.e. p_vaddr not really absolute).

dwfl_segment_report_module sees nothing at 0x400000 because the text is
entirely elided, so we're in the call starting its search at the 0x600000
segment.  This is actually the second LOAD with offset aligned== 0, but we
think it's the first.  Hence:

0x400000+0x200b48 - /home/roland/redhat/tmp/dl3 - 
0x600000+0x201000 - . - [exe]

because the [exe] should have been seen to start at 0x400000.

I'm thinking the way to solve this involves looking if the preceding
segment has no module and precedes immediately, to decide the current
segment is really the later LOAD of 0, not the earlier one.  
Needs more thought.


Thanks,
Roland