I think we should do 0.141 after another day or two for testing and verification. It has some needed fixes, and makes two Fedora secondary arch ports newly happy.
All looks good on my end. I'd like to let mjw verify that current git has the problems he hit in stap fixed (RHBZ#489439 and dwfl_module_getsym). "sed -i s/140/141/ configure.ac; autreconf" to test _ELFUTILS_PREREQ code.
$ git log --abbrev-commit --pretty=oneline --reverse elfutils-0.140..master 8651c5e... Fix RHBZ#489439: dwfl_module_build_id yields wrong vaddr for prelinked DSO 329ed9f... __libdwfl_find_build_id optimization nit 6a4bdd9... Add DW_CFA_GNU_negative_offset_extended. d5ff667... Update elf.h and some tables; fill in sparc backend reloc table. dae7be7... Sending translation for po/es.po 4e1b7c9... Sending translation for po/de.po 243fa26... dwfl_module_getsym should not adjust symbols from non-SHF_ALLOC sections. 785dbb1... Fix double-adjust for ET_REL. 68f29f9... Make dwfl_module_getsym yield shndx -1 for any non-allocated section. ec84323... Sending translation for Spanish 04a1416... Fix strip -f infinite loop when coping with some extra kooky object sections. fa25326... Fix RHBZ#494858: fix bad address checks in core file support. 54eb890... NEWS items for notable changes since 0.140 94f4383... Fix error message. eb9ba47... Nominal ARM support.
Thanks, Roland
On Wed, 2009-04-15 at 02:44 -0700, Roland McGrath wrote:
All looks good on my end. I'd like to let mjw verify that current git has the problems he hit in stap fixed (RHBZ#489439 and dwfl_module_getsym). "sed -i s/140/141/ configure.ac; autreconf" to test _ELFUTILS_PREREQ code.
Thanks for the reminder to manually update the version number. At first I forgot. Would it be an idea to up the version number directly after a release in git, so users that test against the elfutils git tree get the _ELFUTILS_PREREQ behavior that will be in effect with the next release?
I did a full make installcheck against systemtap git (7c2136cf) with elfutils git (2fb9051e) on i386 fedora 10 and x86_64 on rhel 5.3 and didn't see any regressions compared with a systemtap build against the system installed elfutils (0.140 for fedora 10, 0.137 for rhel 5.3).
Cheers,
Mark
Thanks for the reminder to manually update the version number. At first I forgot. Would it be an idea to up the version number directly after a release in git, so users that test against the elfutils git tree get the _ELFUTILS_PREREQ behavior that will be in effect with the next release?
I wouldn't mind that if Uli thinks it's OK.
I did a full make installcheck against systemtap git (7c2136cf) with elfutils git (2fb9051e) on i386 fedora 10 and x86_64 on rhel 5.3 and didn't see any regressions compared with a systemtap build against the system installed elfutils (0.140 for fedora 10, 0.137 for rhel 5.3).
So...did that verify that the bugs you've reported were actually fixed, and not just worked around or not happening to come up? IIRC some of your issues were seen on x86_64 and not i386.
Thanks, Roland
On Thu, 2009-04-16 at 13:41 -0700, Roland McGrath wrote:
I did a full make installcheck against systemtap git (7c2136cf) with elfutils git (2fb9051e) on i386 fedora 10 and x86_64 on rhel 5.3 and didn't see any regressions compared with a systemtap build against the system installed elfutils (0.140 for fedora 10, 0.137 for rhel 5.3).
So...did that verify that the bugs you've reported were actually fixed, and not just worked around or not happening to come up? IIRC some of your issues were seen on x86_64 and not i386.
Both issues triggered originally on i386 against libc. The systemtap testsuite doesn't explicitly contain tests for that particular situation (since that would require testers to install all debuginfo, but I am looking into adding something anyway and make them untested if debuginfo isn't found for system libraries used in the test). The code does contain extra workarounds and sanity checks to not trip over these issues.
The dwfl_module_build_id workaround is guarded with a _ELFUTILS_PREREQ, a manual test seems to confirm that against 0.141 we don't need to adjust the returned build_id_vaddr.
The dwfl_module_getsym issue is guarded by two extra sanity checks against the module base. Removing those and just keeping the checks for !(sym.st_shndx == SHN_UNDEF || sym.st_shndx == SHN_ABS || shndxp == -1) and running against the problematic libc instance seems to indicate that also works correctly against 0.141.
Cheers,
Mark
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Roland McGrath wrote:
Thanks for the reminder to manually update the version number. At first I forgot. Would it be an idea to up the version number directly after a release in git, so users that test against the elfutils git tree get the _ELFUTILS_PREREQ behavior that will be in effect with the next release?
I wouldn't mind that if Uli thinks it's OK.
For this the definition of _ELFUTILS_PREREQ would have to be changed to include a sub-minor version number. Right after the release the tree certainly cannot be tagged with the version number of the next release. In glibc I tag the tree with 2.x.90 after the release of 2.x.
- -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
For this the definition of _ELFUTILS_PREREQ would have to be changed to include a sub-minor version number. Right after the release the tree certainly cannot be tagged with the version number of the next release. In glibc I tag the tree with 2.x.90 after the release of 2.x.
I fiddled the magic so _ELFUTILS_VERSION is a 1000 times bigger now and includes the z if version is x.y.z instead of x.y. The _ELFUTILS_PREREQ macro is the same, you can still only check for >= x.y granularity but now configure.ac can say 0.140.90 and this "rounds to ceiling":
#define _ELFUTILS_PREREQ(major, minor) \ ((_ELFUTILS_VERSION + 999) / 1000 >= ((major) * 1000 + (minor)))
Please verify it all seems sane. With this, we'll have to make sure we always use .z for "next .y+=1 pre-test" and never do x.y.1 "minor updates" and such. (The de facto policy now is already to only ever release x.y versions.)
Thanks, Roland
elfutils-devel@lists.fedorahosted.org
-
Mark Wielaard -
Roland McGrath -
Ulrich Drepper