This is the mail archive of the
mailing list for the elfutils project.
Preparing for elfutils 0.161 - Dec 12/15
- From: Mark Wielaard <mjw at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Tue, 02 Dec 2014 11:40:13 +0100
- Subject: Preparing for elfutils 0.161 - Dec 12/15
It is December already. Which means it has been more than 3 months since
the last elfutils 0.160 release. We have had lots of bugfixes and some
new features. So lets see if we are ready for 0.161. My goal is to
release elfutils 0.161 around Friday 12 December/Monday 15 December.
Please try to aim to have anything you really want into elfutils 0.161
in before Friday 12 December. Then we can run tests during the weekend
and if everything looks fine we push out a shiny new release on Monday
15 December. Don't worry too much if something won't make the deadline.
We'll do a new release after ~3 months again.
Some stuff I know people (some CCed) are still working on:
- More robustify fallout from running american fuzzy lop (afl-fuzz).
Most patches I intent to merge have been posted and are still on
mjw/pending. A couple more will probably show up before release once I
have analyzed some more crashers. The biggest outstanding issue is
"unbounded" (actually up to 10 bytes) s/uleb128 reading. I hope to get
support in for length checking when necessary. But this will need some
careful testing because this code is pretty performance critical.
Hanno, if you have any additional results please let us know. I don't
think we can promise elfutils to be fully robust in the face of
deliberately corrupted ELF/DWARF files with 0.161, but we will
certainly be a lot better. I have had afl-fuzz running for some days
now and it now takes hours for new crashers to show up.
- I have been working on some GCC DWARF extensions based on the DWARFv5
draft. This will be experimental for GCC5, but would be nice to
support in elfutils, so people can at least test a little. I suspect
atomic types and alignment attributes might still make it. But this
isn't too important/critical and depends on GCC accepting the patches
- I had been looking at MIPS backend support and Kurt even got me access
to a Debian setup. But I haven't found the time and I am not sure I
can make the time before release. So this might have to move to 0.162.
- Jose said he had some patches/cleanups for the sparc backend which
would be nice to integrate. But they haven't been posted yet. If you
post them I promise to review them ASAP. The only problem will be
testing since there are not many GNU/Linux Sparc machines around.
- For .debug_macro support we still need to finish up the handling of
0xff. The DWARF committee decided they will allow 0xff as user defined
opcode, so we have to act accordingly. I believe Petr already knows
how to properly do this.
- We discussed some flaws in eu-addr2line recently. Josh has some
patches and even more ideas. Lets get at least the bug fix in. We can
deal with "proper" inline frame handling later if we don't make it for
- We also discussed transparent imports of partial units, but I think
there isn't any patches yet. So lets postpone that to next year.
- Jan has some patches for making eu-stack usable as linux kernel
core_pattern handler. Which seem to be generically usable to monitor
exiting processes with eu-stack. But we still need to discuss how far
we want to go with that before committing to an interface/command line
(or maybe just document how the libdwfl interfaces can be used as
Did I forget anything? Please post patches early and often before next
Friday so we know what can still make it into 0.161 and what will be
done next year.