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]

stap libdwfl bug-compatibility requirements


We are preparing to release version 0.138 of elfutils.  I gather that
systemtap might be expecting some buggy old behavior that we've fixed.
I'd like to coordinate on what any such issues are and address them so
users don't experience any regressions.

I'm concerned with two kinds of compatibility.

1. Existing systemtap binaries (including distro packages) linked
   against system elfutils libs do not experience regressions when
   newer elfutils libs are installed.

2. Systemtap binaries built freshly next week from new sources either
   become #1 if built against elfutils-devel < 0.138, or are built so
   they correctly require elfutils-libs >= 0.138 installed to run if
   built against elfutils-devel >= 0.138.

I don't propose to worry about preexisting systemtap sources being
freshly rebuilt against elfutils-devel >= 0.138.

The one bug-compatibility issue I'm aware of where I think systemtap
might be relying on buggy library behavior is dwfl_module_build_id.
In older elfutils, this yields the wrong vaddr: one that (in practice)
points to the byte past the end of the build ID bytes.  In 0.138, it
behaves as decribed and intended: it yields the vaddr of the first
byte of the build ID.

The other case I'm aware of is dwfl_module_relocate_address for prelinked
ET_DYN files with separate debuginfo.  Here AFAIK systemtap has never
relied on the bad behavior.  However, it now has (or shortly will have) a
workaround for the bad behavior that will be unnecessary with 0.138.

Issues in class #1 can be addressed via symbol versioning in libdwfl.
The dwfl_module_build_id function that fresh linking gets you has been
fixed, and it moves into the ELFUTILS_0.138 version set.  libdw.so
also defines a dwfl_module_build_id symbol in the old version set
(ELFUTILS_0.130), which is a bug-compatible wrapper that behaves like
the old library did.

For #2, I propose adding an installed header <elfutils/version.h> that
will define a macro for the elfutils release that these headers and
libraries (i.e. elfutils-devel) come from.  This allows users like
systemtap to test what library behavior they are getting.  You can
either use this in a configure check that does an AC_COMPILE_CHECK on:

	#include <elfutils/version.h>
	#if !_ELFUTILS_PREREQ (0, 138)
	# error "must build with elfutils >= 0.138"
	#endif

or you can use it in the code to make it cope with either:

	#if !_ELFUTILS_PREREQ (0, 138)
	// work around dwfl_module_build_id bug
	id_vaddr -= id_len;
	#endif

I have implemented both of these on the roland/bug-compat branch at
git://git.fedorahosted.org/git/elfutils.git (which see), browse at:
	http://git.fedorahosted.org/git/?p=elfutils.git;a=shortlog;h=refs/heads/roland/bug-compat

I don't propose to implement any bug-compatible wrapper for
dwfl_module_relocate_address.  (You can use _ELFUTILS_PREREQ to optimize
out your workaround when it's not required, but the workaround for that is
correct for new or old, unlike the workaround for dwfl_module_build_id.)

Systemtap folks, please tell me if this covers your issues.
Elfutils folks, please tell me if these changes seem OK.


Thanks,
Roland


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