Preparing for elfutils 0.161 - Dec 12/15

[Mark Wielaard <mjw at redhat dot com>]

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
  first.
- 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.
  Sorry.
- 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.
  http://dwarfstd.org/ShowIssue.php?issue=141001.1
- 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
   such?).

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.

Cheers,

Mark