This is the mail archive of the mailing list for the elfutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
  look at:
  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
  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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]