Preparing for elfutils 0.161 - Dec 12/15

Vicente Olivert Riera Vincent.Riera at
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
>   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.
> - 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

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 mailing list