This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PR12141: danger-detection code for older elfutils


> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]