Re: [PATCH 0/2] libdw: Rewrite the memory handler to be more robust

[Jonathon Anderson <jma14@rice.edu>]

...Drat, I thought I had it this time. Oh well, sorry to make a mess 
again.

The following changes since commit 
6f447ef7f0c5000e88d11312c06df9d5021d4ecd:

  libdwfl: don't bother freeing frames outside of dwfl_thread_getframes 
(2019-10-29 17:48:05 +0100)

are available in the Git repository at:

  <https://github.com/blue42u/elfutils.git> libdw-mem-pr-v2

for you to fetch changes up to 6813732e29766afbe9c1763a5d397f1f51a633d6:

  libdw: Rewrite the memory handler to be more robust. (2019-10-29 
13:35:33 -0500)

----------------------------------------------------------------
Jonathon Anderson (2):
      Add configure options for Valgrind annotations.
      libdw: Rewrite the memory handler to be more robust.

 ChangeLog               |  5 +++++
 configure.ac            | 30 ++++++++++++++++++++++++++++++
 lib/atomics.h           |  2 ++
 libdw/ChangeLog         |  9 +++++++++
 libdw/dwarf_begin_elf.c |  7 ++++---
 libdw/dwarf_end.c       | 24 +++++++++++++-----------
 libdw/libdwP.h          | 67 
++++++++++++++++++++++++++++++++-----------------------------------
 libdw/libdw_alloc.c     | 69 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++----
 8 files changed, 160 insertions(+), 53 deletions(-)

On Tue, Oct 29, 2019 at 21:17, Mark Wielaard <mark@klomp.org> wrote:
> Hi Jonathon,
> 
> On Tue, Oct 29, 2019 at 01:55:25PM -0500, Jonathon Anderson wrote:
>>  This is (revived and rebased) version of the libdw memory manager 
>> that isn't
>>  affected by the PTHREAD_KEYS_MAX limit. There are some downsides, in
>>  particular if an application spawns many short-lived threads that 
>> all touch
>>  a Dwarf (enough to cause an allocation), there's about ~8N bytes of 
>> memory
>>  overhead.
> 
> Thanks. But it looks like your mail client munged the patches a bit
> making it a bit tricky to apply. Could you resent them using git
> send-email or do you have some public repo I could get them from?
> 
> Thanks,
> 
> Mark