Re: [PATCH 2/5] libdwfl: only use thread->unwound for initial frame

2019-10-29 Thread Mark Wielaard
Hi Omar, On Mon, Oct 07, 2019 at 02:05:36AM -0700, Omar Sandoval wrote: > thread->unwound is only used for set_initial_registers (via > dwfl_thread_state_registers, dwfl_thread_state_register_pc, and a > special case in core_set_initial_registers). At that point, > thread->unwound is always the in

[PATCH 1/2] Add configure options for Valgrind annotations.

2019-10-29 Thread Mark Wielaard
From: Jonathon Anderson Signed-off-by: Jonathon Anderson --- ChangeLog| 5 + configure.ac | 30 ++ 2 files changed, 35 insertions(+) diff --git a/ChangeLog b/ChangeLog index 911cf354..433a5f3c 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2019-08-

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

2019-10-29 Thread Mark Wielaard
From: Jonathon Anderson Pthread's thread-local variables are highly limited, which makes it difficult to use many Dwarfs. This replaces that with a less efficient (or elegant) but more robust method. Signed-off-by: Jonathon Anderson --- lib/atomics.h | 2 ++ libdw/ChangeLog

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

2019-10-29 Thread Jonathon Anderson
...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

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

2019-10-29 Thread Mark Wielaard
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

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

2019-10-29 Thread Jonathon Anderson
[PATCH 2/2] libdw: Rewrite the memory handler to be more robust. Pthread's thread-local variables are highly limited, which makes it difficult to use many Dwarfs. This replaces that with a less efficient (or elegant) but more robust method. Signed-off-by: Jonathon Anderson --- lib/atomics.h

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

2019-10-29 Thread Jonathon Anderson
[PATCH 1/2] Add configure options for Valgrind annotations. Signed-off-by: Jonathon Anderson --- ChangeLog| 5 + configure.ac | 30 ++ 2 files changed, 35 insertions(+) diff --git a/ChangeLog b/ChangeLog index 911cf354..433a5f3c 100644 --- a/ChangeLog +++ b/Ch

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

2019-10-29 Thread Jonathon Anderson
Hello, 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

Re: [PATCH 1/5] libdwfl: don't bother freeing frames outside of dwfl_thread_getframes

2019-10-29 Thread Mark Wielaard
On Tue, 2019-10-29 at 09:17 -0700, Omar Sandoval wrote: > Unless I missed something, the only place we allocate the state is > from dwfl_thread_getframes, and we always free it before returning from > that function. So if you're not using dwfl_thread_getframes, dwfl_getthreads > won't have anything

Re: [PATCH 1/5] libdwfl: don't bother freeing frames outside of dwfl_thread_getframes

2019-10-29 Thread Omar Sandoval
On Tue, Oct 29, 2019 at 04:55:27PM +0100, Mark Wielaard wrote: > Hi Omar, > > On Mon, 2019-10-07 at 02:05 -0700, Omar Sandoval wrote: > > dwfl_thread_getframes always frees the state before returning, so > > dwfl_getthreads and getthread don't need to do it. > > I am not sure I follow. dwfl_getth

Re: [PATCH 1/5] libdwfl: don't bother freeing frames outside of dwfl_thread_getframes

2019-10-29 Thread Mark Wielaard
Hi Omar, On Mon, 2019-10-07 at 02:05 -0700, Omar Sandoval wrote: > dwfl_thread_getframes always frees the state before returning, so > dwfl_getthreads and getthread don't need to do it. I am not sure I follow. dwfl_getthreads can be used independently from its (indirect) usage from dwfl_thread_ge

[Bug tools/25069] AddressSanitizer: heap-buffer-overflow at libdwelf/dwelf_strtab.c:284

2019-10-29 Thread mark at klomp dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=25069 Mark Wielaard changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---