Hi, The last release had lots of new features. I don't have any grand plans for the next release. I was mostly going to spend time on bug fixing and cleanups. The following items is just what I personally wanted to spend some time on. I don't think everything below makes it for the next release (0.159 lets say somewhere in March). And I might have forgotten stuff. But it is probably what I will spend some time on next.
- Bugs, there are more, but these two were what I wanted to at least look at: https://bugzilla.redhat.com/show_bug.cgi?id=1037051 elfutils FTBFS if "-Werror=format-security" flag is used Currently we just remove that flag, but if we can rewrite the code to enable it by default for all files that would be nice. Dunno if that is really possible in all cases though. https://bugzilla.redhat.com/show_bug.cgi?id=1020842 libelf: segment fault on x86-64 while file's bss offset have a large number This slipped through the cracks, there has even been a patch proposed on the list: http://thread.gmane.org/gmane.comp.sysutils.elfutils.devel/3181 And lets see what else people report. https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&component=elfutils - Merge robustify commits to master if they make sense. And look at the portable branch patches suggested by Mike Frysinger https://lists.fedorahosted.org/pipermail/elfutils-devel/2014-January/003698.html - Move .gnu_debugaltlink handling from libdw to libdwfl and make ENABLE_DWZ the default. As discussed before: https://lists.fedorahosted.org/pipermail/elfutils-devel/2013-December/003626.html - string functions (this would be a new feature). I abandoned this since it was a lot of work for such a small feature and we were right before a release. But I keep writing code that would be much easier if we had string functions for the common DWARF constants. This would resurrect: https://git.fedorahosted.org/cgit/elfutils.git/log/?h=mjw/dwarfstrings - speedup/cache __libdwfl_addrsym. This is the main reason eu-readelf (without -N) and to a lesser extend eu-stack (without -q) is so slow. They do address lookups without any caching, so they potentially need to search through all of them each time. It has been discussed before. https://lists.fedorahosted.org/pipermail/elfutils-devel/2013-July/003126.html Needs lots of testing to make sure the results returned are equal. - Jan's idea to use /proc/PID/map_files when available seems very attractive: https://lists.fedorahosted.org/pipermail/elfutils-devel/2013-December/003637.html As an alternative fallback we can try to reuse the technique we are already using in dwfl_linux_proc_find_elf for extracting the vdso through getting the in-memory ELF image from the target process. I got this working through some ugly hacks. elf_from_remote_memory does work for the vdso, but not always for other images. That code needs to be cleaned up and we need to find a way to pass information about the target pid from the dwfl_linux_proc_report callback to the dwfl_linux_proc_find_elf callback (or maybe introduce new report and find_elf callbacks for this functionality). - unwinder backends for aarch64 and arm7hl - aarch64 is mostly there on my branch https://git.fedorahosted.org/cgit/elfutils.git/log/?h=mjw/aarch64-unwind But needs actual testing and last time I played with it glibc didn't seem to properly mark _start and _clone causing the link register to point to the current pc and gcc didn't always seem to produce .eh_frame for all functions. So might need some interaction with the rest of the toolchain to make sure everything is correct. - arm32 might be a bit tricky. When there is a .debug_frame it should be simple. If not, then we might just give up for now. Or add a EXIDX to CFI translator fallback to the backend. - Maybe tweak the defaults for eu-stack based on feedback. Maybe use more debug information than just the line numbers if available (e.g. use the subprogram or inlined_subroutine names for the addresses found). Not all the above might make it before 0.159, and maybe some other stuff that I forgot about pops up, but it is a start and should keep me busy till March. And of course we can push out a new release earlier if some really nasty regressions/bugs are found and fixed before that. Cheers, Mark
