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. > 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 >
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? Thanks. -- Vicente Olivert Riera Graduate Software Engineer, MIPS Platforms Imagination Technologies Limited t: +44 (0)113 2429814 www.imgtec.com
