Fix false match of non-build-id disk library to build-id memory library.
this patch:
Use DT_DEBUG library search first.
8ff862960efb648cdff647d7fad1be5acffe9b11
[patch 2/2] Fix loading core files without build-ids
https://lists.fedorahosted.org/pipermail/elfutils-devel/2013-April/003031.html
[patch 2/2 v2] Fix loading core files without build-ids
https://lists.fedorahosted.org/pipermail/elfutils-devel/2013-May/003065.html
has PASS->FAIL regression on CentOS-5 for run-unstrip-n.sh:
-actual on CentOS-5
+expected by testcase
-0xf77b3000+0x822c - /lib/librt.so.1 - librt.so.1
-0xf7603000+0x15c5c4 - /lib/libc.so.6 - libc.so.6
-0xf75e9000+0x191e4 - /lib/libpthread.so.0 - libpthread.so.0
-0xf77d7000+0x1c670 - /lib/ld-linux.so.2 - ld-linux.so.2
0x8048000+0x2000 f1c600bc36cb91bf01f9a63a634ecb79aa4c3199@0x8048178 . - [exe]
+0xf75e9000+0x1a000 29a103420abe341e92072fb14274e250e4072148@0xf75e9164 - - libpthread.so.0
+0xf7603000+0x1b0000 0b9bf374699e141e5dfc14757ff42b8c2373b4de@0xf7603184 - - libc.so.6
+0xf77b3000+0x9000 c6c5b5e35ab9589d4762ac85b4bd56b1b2720e37@0xf77b3164 - - librt.so.1
0xf77d6000+0x1000 676560b1b765cde9c2e53f134f4ee354ea894747@0xf77d6210 . - linux-gate.so.1
+0xf77d7000+0x21000 6d2cb32650054f1c176d01d48713a4a5e5e84c1a@0xf77d7124 - - ld-linux.so.2
Therefore elfutils now incorrectly matches on-disk file without build-id to an
in-core (in-memory) file with build-id.
In fact due to its known FIXME:
This verification gives false positive if in-core ELF had
build-id but on-disk ELF does not have any. But we cannot
reliably find ELF header and/or the ELF build id just from
the link map (and checking core segments is also not
reliable). */
So it probably should not be so ignorable as I did, one may want to analyze
build-id core files on CentOS-5, not sure. In fact it can be fixed, when we
find in dwfl_segment_report_module a module with build-id with conflicts in
its address range with existing non-build-id dwfl_link_map_report module we
should prefer the build-id module instead.
The problem is that once Dwfl_Module is added to Dwfl it cannot be easily
removed.
Originally elfutils called dwfl_segment_report_module first and then
dwfl_link_map_report.
Currently the order is dwfl_link_map_report and then
dwfl_segment_report_module only for modules missing from dwfl_link_map_report.
Patch below unfortunately needs bidirectional negotiation between the two
functions, therefore dwfl_link_map_report now no longer adds Dwfl_Modules to
Dwfl but it only stores information about them to r_debug_info_module.
This information is filtered then by dwfl_segment_report_module and only
filtered r_debug_info_module entries get finally added to Dwfl
(in dwfl_core_file_report).
NT_FILE would make all this magic easy but it is true that on CentOS-5 it
definitely does not exist.
libdwfl/
2013-07-23 Jan Kratochvil <jan.kratochvil@redhat.com>
* core-file.c (clear_r_debug_info): Close also ELF and FD.
(dwfl_core_file_report): Call __libdwfl_report_elf for
R_DEBUG_INFO.MODULE.
* dwfl_report_elf.c (__libdwfl_elf_address_range): New function from
code of ...
(__libdwfl_report_elf): ... this function. Call it.
* dwfl_segment_report_module.c: Include unistd.h.
(dwfl_segment_report_module): Use basename for MODULE->NAME.
Clear MODULE if it has no build-id and we have segment with build-id.
Ignore this segment only if MODULE still contains valid ELF.
* libdwflP.h (__libdwfl_elf_address_range): New declaration.
(struct r_debug_info_module): New fields fd, elf, l_addr, start, end
and disk_file_has_build_id.
(dwfl_link_map_report): Extend the comment.
* link_map.c (report_r_debug): Extend the comment. Always fill in new
r_debug_info_module. Initialize also the new r_debug_info_module
fields. Remove one FIXME comment. Call __libdwfl_elf_address_range
instead of __libdwfl_report_elf when R_DEBUG_INFO is not NULL.
tests/
2013-07-23 Jan Kratochvil <jan.kratochvil@redhat.com>
* run-unstrip-n.sh (test-core.*): Ignore libc.so.6 entry and order of
the entries.
Signed-off-by: Jan Kratochvil <jan.kratochvil@redhat.com>
8 files changed