mirror of
https://github.com/openharmony/third_party_elfutils.git
synced 2026-07-20 23:45:11 -04:00
Jan Kratochvil
596d430f23
this patch:
Use DT_DEBUG library search first.
8ff862960e
[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>
Fundamental design decision: - the sizes of external and internal types are assumed to be the same. This leaves byte ordering aside. While assuming this the code can be greatly simplified and speed increases. Since no change violating this assumption is in sight this is believed to be a worthwhile optimization. - the ABI of the backend modules is not guaranteed. Really, not guarantee whatsoever. We are enforcing this in the code. The modules and their users must match. No third-party EBL module are supported or allowed. The only reason there are separate modules is to not have the code for all architectures in all the binaries.