This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: PR12141: danger-detection code for older elfutils
- From: Roland McGrath <roland at redhat dot com>
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: systemtap at sources dot redhat dot com
- Date: Mon, 15 Nov 2010 15:44:26 -0800 (PST)
- Subject: Re: PR12141: danger-detection code for older elfutils
- References: <20101114020130.GE21705@redhat.com>
> I believe the first one is
> type==ET_DYN && has_section(.gnu.prelink_undo)
That will catch many more cases than really have a problem.
The problem can only exist if it's a prelinked library (or PIE) with a
separate .debug file, where prelink was done after the .debug file was
separated (as is normal for packaged builds). If you are not using a
separate .debug file, there is nothing to worry about.
It's also possible for a particular library not to have required the
REL->RELA conversion when it was prelinked.
(It depends on the details of the relocations used.)
If it's an ET_DYN, then you can examine the phdrs of the main and
debug files, if they are not the same file. Check the first PT_LOAD
in each file. If the p_memsz fields differ, then the file is
susceptible to the libdwfl bug.
> Could you commit a macro or somesuch to libdwfl.h that would allow us
> to autoconf the presence of the related bugfix?
There is no ABI change associated with this fix (nor any at all that will
be in 0.150). So you can't rely on _ELFUTILS_PREREQ (0, 150) as you might
think, because that only tells you that you linked with the new elfutils
libraries at build time, but you might still be using (ABI-compatible)
older ones at runtime.
You can do a runtime test:
if (strverscmp (dwfl_version (dwfl), "0.149") > 0)
...fixed...
else
...not fixed...
(You can actually pass NULL to dwfl_version, but probably better not
to, since passing the pointer is the documented API.)
Thanks,
Roland