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
elfutils-devel@lists.fedorahosted.org