This is the mail archive of the
mailing list for the elfutils project.
Some stuff for 0.159+
- From: Mark Wielaard <mjw at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Wed, 15 Jan 2014 16:16:34 +0100
- Subject: Some stuff for 0.159+
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
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.
libelf: segment fault on x86-64
while file's bss offset have a large
This slipped through the cracks, there has even been a patch proposed
on the list:
And lets see what else people report.
- Merge robustify commits to master if they make sense.
And look at the portable branch patches suggested by Mike Frysinger
- Move .gnu_debugaltlink handling from libdw to libdwfl and make
ENABLE_DWZ the default. As discussed before:
- 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:
- 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.
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
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
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
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.