On Mon, 2012-08-13 at 21:01 +0200, Mark Wielaard wrote:
But this comes back to my comment on the other patch.
In the case of readelf.c this makes sense, since it uses libdwfl
to access the elf data it can "transparently" read the compressed
data. But other callers might not be able to process compressed
sections. So I think we should carefully audit all callers to
make sure that if debugscn_p () returns true for a compressed
section then they are actually able to process the data.
So a quick scan of uses of ebl_debugscn_p, ebl_section_strip_p and
SECTION_STRIP_P:
- libdwfl/relocate.c (relocate_section)
Uses elf_rawdata () so won't be able to handle the section.
- src/elfcmp.c seems fine, just checks both files have the same stripped
out sections.
- src/strip.c ebl_section_strip_p usage looks fine since it doesn't
interpret the section data, but a testcase would be nice. But
ebl_debugscn_p is used to see if --reloc-debug-sections makes
sense, and it won't be able to handle zdebug sections.
- libelf/elf32_checksum.c: Seems fine since it just uses the raw
data to calculate the checksum. O, and it seems SECTION_STRIP_P
doesn't actually depend on ebl_debugscn_p anymore, despite the
/* The SECTION_STRIP_P macro wants to call into libebl which we cannot
do and do not have to do here. Provide a dummy replacement. */
#define ebl_debugscn_p(ebl, name) true
We should probably remove that then while we are at it.
- src/ldgeneric.c and src/ldscript.y might be fine, but I don't
really know this code.
- src/readelf.c doesn't use it yet, but this patch will introduce it.
Should be fine since all section data is accessed through libdw which
would have uncompressed it.
Cheers,
Mark