[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|--- |FIXED

--- Comment #6 from Mark Wielaard  ---
commit b23389a8005a7e93bc21b2932156899e1aac
Author: Mark Wielaard 
Date:   Sat Oct 26 22:54:49 2019 +0200

unstrip: Check symbol strings are terminated.

A corrupt ELF file could contain a .strtab section that wasn't
properly zero terminated. If so we could add a non-terminated string
to the dwelf_strtab functions, which could then crash because they
would read past the .strtab section data.

https://sourceware.org/bugzilla/show_bug.cgi?id=25069

Signed-off-by: Mark Wielaard 

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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_getframes. So doesn't it need to
do its own cleanup?

Thanks,

Mark


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_getthreads can be used independently from
> its (indirect) usage from dwfl_thread_getframes. So doesn't it need to
> do its own cleanup?

Hi, Mark,

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 to free, and if you are, dwfl_thread_getframes
already freed it. Or am I missing something?

Thanks,
Omar


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 to free, and if you are, dwfl_thread_getframes
> already freed it. Or am I missing something?

O, you are right. Sorry, I missed that. Now that I understand what is
going on it actually is odd that the other functions try to free the
state. They cannot know whether that is what their caller wants. So
yes, this makes sense. Added that extra sentence to the commit message
and pushed to master.

Thanks,

Mark


[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 of memory overhead.


The first patch is not required and adds some configure-time options 
for Valgrind annotation support (although, I'm not a serious autotools 
user, so it might need some work).


-Jonathon


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(-)



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/ChangeLog
@@ -1,3 +1,8 @@
+2019-08-25  Jonathon Anderson 
+
+   * configure.ac: Add new --enable-valgrind-annotations
+   * configure.ac: Add new --with-valgrind (headers only)
+
2019-07-05  Omar Sandoval  

* configure.ac: Get rid of --enable-libebl-subdir.
diff --git a/configure.ac b/configure.ac
index 9be34d12..7fc3acb6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -335,6 +335,35 @@ if test "$use_valgrind" = yes; then
fi
AM_CONDITIONAL(USE_VALGRIND, test "$use_valgrind" = yes)

+AC_ARG_WITH([valgrind],
+AS_HELP_STRING([--with-valgrind],[include directory for Valgrind 
headers]),

+[with_valgrind_headers=$withval], [with_valgrind_headers=no])
+if test "x$with_valgrind_headers" != xno; then
+save_CFLAGS="$CFLAGS"
+CFLAGS="$CFLAGS -I$with_valgrind_headers"
+AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
+  #include 
+  int main() { return 0; }
+]])], [ HAVE_VALGRIND_HEADERS="yes"
+CFLAGS="$save_CFLAGS -I$with_valgrind_headers" ],
+  [ AC_MSG_ERROR([invalid valgrind include directory: 
$with_valgrind_headers]) ])

+fi
+
+AC_ARG_ENABLE([valgrind-annotations],
+AS_HELP_STRING([--enable-valgrind-annotations],[insert extra 
annotations for better valgrind support]),

+[use_vg_annotations=$enableval], [use_vg_annotations=no])
+if test "$use_vg_annotations" = yes; then
+if test "x$HAVE_VALGRIND_HEADERS" != "xyes"; then
+  AC_MSG_CHECKING([whether Valgrind headers are available])
+  AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
+#include 
+int main() { return 0; }
+  ]])], [ AC_MSG_RESULT([yes]) ],
+[ AC_MSG_ERROR([valgrind annotations requested but no 
headers are available]) ])

+fi
+fi
+AM_CONDITIONAL(USE_VG_ANNOTATIONS, test "$use_vg_annotations" = yes)
+
AC_ARG_ENABLE([install-elfh],
AS_HELP_STRING([--enable-install-elfh],[install elf.h in include dir]),
   [install_elfh=$enableval], [install_elfh=no])
@@ -669,6 +698,7 @@ AC_MSG_NOTICE([
  OTHER FEATURES
Deterministic archives by default  : ${default_ar_deterministic}
Native language support: ${USE_NLS}
+Extra Valgrind annotations : ${use_vg_annotations}

  EXTRA TEST FEATURES (used with make check)
have bunzip2 installed (required)  : ${HAVE_BUNZIP2}
--
2.24.0.rc1




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   |  2 ++
libdw/ChangeLog |  9 ++
libdw/dwarf_begin_elf.c |  7 +++--
libdw/dwarf_end.c   | 24 +++---
libdw/libdwP.h  | 67 +++
libdw/libdw_alloc.c | 69 ++---
6 files changed, 125 insertions(+), 53 deletions(-)

diff --git a/lib/atomics.h b/lib/atomics.h
index ffd12f87..e3773759 100644
--- a/lib/atomics.h
+++ b/lib/atomics.h
@@ -31,7 +31,9 @@
#if HAVE_STDATOMIC_H
/* If possible, use the compiler's preferred atomics.  */
# include 
+# include 
#else
/* Otherwise, try to use the builtins provided by this compiler.  */
# include "stdatomic-fbsd.h"
+# define thread_local __thread
#endif /* HAVE_STDATOMIC_H */
diff --git a/libdw/ChangeLog b/libdw/ChangeLog
index 394c0df2..8de8a837 100644
--- a/libdw/ChangeLog
+++ b/libdw/ChangeLog
@@ -1,3 +1,12 @@
+2019-10-28  Jonathon Anderson  
+
+   * libdw_alloc.c: Added __libdw_alloc_tail.
+   (__libdw_allocate): Switch to use the mem_tails array.
+   * libdwP.h (Dwarf): Likewise.
+   * dwarf_begin_elf.c (dwarf_begin_elf): Support for above.
+   * dwarf_end.c (dwarf_end): Likewise.
+   * atomics.h: Add support for thread_local.
+
2019-08-26  Jonathon Anderson  

* libdw_alloc.c (__libdw_allocate): Added thread-safe stack allocator.
diff --git a/libdw/dwarf_begin_elf.c b/libdw/dwarf_begin_elf.c
index 8d137414..eadff13b 100644
--- a/libdw/dwarf_begin_elf.c
+++ b/libdw/dwarf_begin_elf.c
@@ -418,13 +418,14 @@ dwarf_begin_elf (Elf *elf, Dwarf_Cmd cmd, Elf_Scn 
*scngrp)

 actual allocation.  */
  result->mem_default_size = mem_default_size;
  result->oom_handler = __libdw_oom;
-  if (pthread_key_create (&result->mem_key, NULL) != 0)
+  if (pthread_rwlock_init(&result->mem_rwl, NULL) != 0)
{
  free (result);
-  __libdw_seterrno (DWARF_E_NOMEM); /* no memory or max pthread 
keys.  */

+  __libdw_seterrno (DWARF_E_NOMEM); /* no memory.  */
  return NULL;
}
-  atomic_init (&result->mem_tail, (uintptr_t)NULL);
+  result->mem_stacks = 0;
+  result->mem_tails = NULL;

  if (cmd == DWARF_C_READ || cmd == DWARF_C_RDWR)
{
diff --git a/libdw/dwarf_end.c b/libdw/dwarf_end.c
index a2e94436..3fd2836d 100644
--- a/libdw/dwarf_end.c
+++ b/libdw/dwarf_end.c
@@ -95,17 +95,19 @@ dwarf_end (Dwarf *dwarf)
  tdestroy (dwarf->split_tree, noop_free);

  /* Free the internally allocated memory.  */
-  struct libdw_memblock *memp;
-  memp = (struct libdw_memblock *) (atomic_load_explicit
-   (&dwarf->mem_tail,
-memory_order_relaxed));
-  while (memp != NULL)
-   {
- struct libdw_memblock *prevp = memp->prev;
- free (memp);
- memp = prevp;
-   }
-  pthread_key_delete (dwarf->mem_key);
+  for (size_t i = 0; i < dwarf->mem_stacks; i++)
+{
+  struct libdw_memblock *memp = dwarf->mem_tails[i];
+  while (memp != NULL)
+   {
+ struct libdw_memblock *prevp = memp->prev;
+ free (memp);
+ memp = prevp;
+   }
+}
+  if (dwarf->mem_tails != NULL)
+free (dwarf->mem_tails);
+  pthread_rwlock_destroy (&dwarf->mem_rwl);

  /* Free the pubnames helper structure.  */
  free (dwarf->pubnames_sets);
diff --git a/libdw/libdwP.h b/libdw/libdwP.h
index ad2599eb..3e1ef59b 100644
--- a/libdw/libdwP.h
+++ b/libdw/libdwP.h
@@ -149,17 +149,6 @@ enum

#include "dwarf_sig8_hash.h"

-/* Structure for internal memory handling.  This is basically a 
simplified

-   reimplementation of obstacks.  Unfortunately the standard obstack
-   implementation is not usable in libraries.  */
-struct libdw_memblock
-{
-  size_t size;
-  size_t remaining;
-  struct libdw_memblock *prev;
-  char mem[0];
-};
-
/* This is the structure representing the debugging state.  */
struct Dwarf
{
@@ -231,11 +220,22 @@ struct Dwarf
  /* Similar for addrx/constx, which will come from .debug_addr 
section.  */

  struct Dwarf_CU *fake_addr_cu;

-  /* Internal memory handling.  Each thread allocates separately and 
only
- allocates from its own blocks, while all the blocks are pushed 
atomically

- onto a unified stack for easy deallocation.  */
-  pthread_key_t mem_key;
-  atomic_uintptr_t mem_tail;
+  /* Supporting lock for internal memory handling.  Ensures threads 
that have
+ an entry in the mem_tails array are not disturbed by new threads 
doing

+ allocations for this Dwarf.  */
+  pthread_rwlock_t mem_rwl;
+
+  /* Internal memory handling.  This is basically a simplified 
thread-local

+ reimplementation of obstacks.  Unfortunately the

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 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


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:

  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  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




[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 |  9 ++
 libdw/dwarf_begin_elf.c |  7 +++--
 libdw/dwarf_end.c   | 24 +++---
 libdw/libdwP.h  | 67 +++
 libdw/libdw_alloc.c | 69 ++---
 6 files changed, 125 insertions(+), 53 deletions(-)

diff --git a/lib/atomics.h b/lib/atomics.h
index ffd12f87..e3773759 100644
--- a/lib/atomics.h
+++ b/lib/atomics.h
@@ -31,7 +31,9 @@
 #if HAVE_STDATOMIC_H
 /* If possible, use the compiler's preferred atomics.  */
 # include 
+# include 
 #else
 /* Otherwise, try to use the builtins provided by this compiler.  */
 # include "stdatomic-fbsd.h"
+# define thread_local __thread
 #endif /* HAVE_STDATOMIC_H */
diff --git a/libdw/ChangeLog b/libdw/ChangeLog
index 394c0df2..8de8a837 100644
--- a/libdw/ChangeLog
+++ b/libdw/ChangeLog
@@ -1,3 +1,12 @@
+2019-10-28  Jonathon Anderson  
+
+   * libdw_alloc.c: Added __libdw_alloc_tail.
+   (__libdw_allocate): Switch to use the mem_tails array.
+   * libdwP.h (Dwarf): Likewise.
+   * dwarf_begin_elf.c (dwarf_begin_elf): Support for above.
+   * dwarf_end.c (dwarf_end): Likewise.
+   * atomics.h: Add support for thread_local.
+
 2019-08-26  Jonathon Anderson  
 
* libdw_alloc.c (__libdw_allocate): Added thread-safe stack allocator.
diff --git a/libdw/dwarf_begin_elf.c b/libdw/dwarf_begin_elf.c
index 8d137414..eadff13b 100644
--- a/libdw/dwarf_begin_elf.c
+++ b/libdw/dwarf_begin_elf.c
@@ -418,13 +418,14 @@ dwarf_begin_elf (Elf *elf, Dwarf_Cmd cmd, Elf_Scn *scngrp)
  actual allocation.  */
   result->mem_default_size = mem_default_size;
   result->oom_handler = __libdw_oom;
-  if (pthread_key_create (&result->mem_key, NULL) != 0)
+  if (pthread_rwlock_init(&result->mem_rwl, NULL) != 0)
 {
   free (result);
-  __libdw_seterrno (DWARF_E_NOMEM); /* no memory or max pthread keys.  */
+  __libdw_seterrno (DWARF_E_NOMEM); /* no memory.  */
   return NULL;
 }
-  atomic_init (&result->mem_tail, (uintptr_t)NULL);
+  result->mem_stacks = 0;
+  result->mem_tails = NULL;
 
   if (cmd == DWARF_C_READ || cmd == DWARF_C_RDWR)
 {
diff --git a/libdw/dwarf_end.c b/libdw/dwarf_end.c
index a2e94436..3fd2836d 100644
--- a/libdw/dwarf_end.c
+++ b/libdw/dwarf_end.c
@@ -95,17 +95,19 @@ dwarf_end (Dwarf *dwarf)
   tdestroy (dwarf->split_tree, noop_free);
 
   /* Free the internally allocated memory.  */
-  struct libdw_memblock *memp;
-  memp = (struct libdw_memblock *) (atomic_load_explicit
-   (&dwarf->mem_tail,
-memory_order_relaxed));
-  while (memp != NULL)
-   {
- struct libdw_memblock *prevp = memp->prev;
- free (memp);
- memp = prevp;
-   }
-  pthread_key_delete (dwarf->mem_key);
+  for (size_t i = 0; i < dwarf->mem_stacks; i++)
+{
+  struct libdw_memblock *memp = dwarf->mem_tails[i];
+  while (memp != NULL)
+   {
+ struct libdw_memblock *prevp = memp->prev;
+ free (memp);
+ memp = prevp;
+   }
+}
+  if (dwarf->mem_tails != NULL)
+free (dwarf->mem_tails);
+  pthread_rwlock_destroy (&dwarf->mem_rwl);
 
   /* Free the pubnames helper structure.  */
   free (dwarf->pubnames_sets);
diff --git a/libdw/libdwP.h b/libdw/libdwP.h
index ad2599eb..3e1ef59b 100644
--- a/libdw/libdwP.h
+++ b/libdw/libdwP.h
@@ -149,17 +149,6 @@ enum
 
 #include "dwarf_sig8_hash.h"
 
-/* Structure for internal memory handling.  This is basically a simplified
-   reimplementation of obstacks.  Unfortunately the standard obstack
-   implementation is not usable in libraries.  */
-struct libdw_memblock
-{
-  size_t size;
-  size_t remaining;
-  struct libdw_memblock *prev;
-  char mem[0];
-};
-
 /* This is the structure representing the debugging state.  */
 struct Dwarf
 {
@@ -231,11 +220,22 @@ struct Dwarf
   /* Similar for addrx/constx, which will come from .debug_addr section.  */
   struct Dwarf_CU *fake_addr_cu;
 
-  /* Internal memory handling.  Each thread allocates separately and only
- allocates from its own blocks, while all the blocks are pushed atomically
- onto a unified stack for easy deallocation.  */
-  pthread_key_t mem_key;
-  atomic_uintptr_t mem_tail;
+  /* Supporting lock for internal memory handling.  Ensures threads that have
+ an entry in the mem_tails array are not disturbed by new threads doing
+ allocations for this Dwarf.  */
+  pthread_rwlock_t mem_rwl;
+
+  /* Internal memory handling.  This is basically a simplified thread-local
+ reimplementation of obstacks.  Unfortunately the standard obstac

[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-25  Jonathon Anderson 
+
+   * configure.ac: Add new --enable-valgrind-annotations
+   * configure.ac: Add new --with-valgrind (headers only)
+
 2019-07-05  Omar Sandoval  
 
* configure.ac: Get rid of --enable-libebl-subdir.
diff --git a/configure.ac b/configure.ac
index 9be34d12..7fc3acb6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -335,6 +335,35 @@ if test "$use_valgrind" = yes; then
 fi
 AM_CONDITIONAL(USE_VALGRIND, test "$use_valgrind" = yes)
 
+AC_ARG_WITH([valgrind],
+AS_HELP_STRING([--with-valgrind],[include directory for Valgrind headers]),
+[with_valgrind_headers=$withval], [with_valgrind_headers=no])
+if test "x$with_valgrind_headers" != xno; then
+save_CFLAGS="$CFLAGS"
+CFLAGS="$CFLAGS -I$with_valgrind_headers"
+AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
+  #include 
+  int main() { return 0; }
+]])], [ HAVE_VALGRIND_HEADERS="yes"
+CFLAGS="$save_CFLAGS -I$with_valgrind_headers" ],
+  [ AC_MSG_ERROR([invalid valgrind include directory: 
$with_valgrind_headers]) ])
+fi
+
+AC_ARG_ENABLE([valgrind-annotations],
+AS_HELP_STRING([--enable-valgrind-annotations],[insert extra annotations for 
better valgrind support]),
+[use_vg_annotations=$enableval], [use_vg_annotations=no])
+if test "$use_vg_annotations" = yes; then
+if test "x$HAVE_VALGRIND_HEADERS" != "xyes"; then
+  AC_MSG_CHECKING([whether Valgrind headers are available])
+  AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
+#include 
+int main() { return 0; }
+  ]])], [ AC_MSG_RESULT([yes]) ],
+[ AC_MSG_ERROR([valgrind annotations requested but no headers are 
available]) ])
+fi
+fi
+AM_CONDITIONAL(USE_VG_ANNOTATIONS, test "$use_vg_annotations" = yes)
+
 AC_ARG_ENABLE([install-elfh],
 AS_HELP_STRING([--enable-install-elfh],[install elf.h in include dir]),
[install_elfh=$enableval], [install_elfh=no])
@@ -669,6 +698,7 @@ AC_MSG_NOTICE([
   OTHER FEATURES
 Deterministic archives by default  : ${default_ar_deterministic}
 Native language support: ${USE_NLS}
+Extra Valgrind annotations : ${use_vg_annotations}
 
   EXTRA TEST FEATURES (used with make check)
 have bunzip2 installed (required)  : ${HAVE_BUNZIP2}
-- 
2.20.1



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 initial frame, so there's no need to
> update it as we unwind the stack. Let's set it to NULL after we do the
> initial setup. This simplifies the next change.

Very nice cleanup. Pushed to master.

Thanks,

Mark