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
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-
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
...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
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
[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
[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
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
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
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
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
https://sourceware.org/bugzilla/show_bug.cgi?id=25069
Mark Wielaard changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
12 matches
Mail list logo