Preparing for elfutils 0.161 - Dec 12/15
Vicente Olivert Riera
Vincent.Riera at imgtec.com
Tue Dec 2 10:43:35 UTC 2014
Dear Mark Wielaard,
On 12/02/2014 10:40 AM, Mark Wielaard wrote:
> Hi Hackers,
> 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
> next Friday.
> - 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.
I have one request for you. When you release the new 0.161, could you
please also add a version number to the portability patch?
Vicente Olivert Riera
Graduate Software Engineer, MIPS Platforms
Imagination Technologies Limited
t: +44 (0)113 2429814
More information about the elfutils-devel