Hello,
I am quite new on elfutils library. I know their were discussions in
the past about the question I will ask but let me introduce my use
case.
I am working on a project which aims at building some kind of
"standalone" toolchain (binutils, gcc, clang + tools like gdb,
valgrind). This toolcha
Understood.
In this case, there are 2 solutions:
- we completely remove the call to dlopen
- we keep the call to dlopen from the shared lib version of libdw and
embed all the backends code in the archive
I don't know if the second solution is worth the additional
work/complexity. What do you thi
On irc Tom pointed out that no was yes... oops.
Committed as obvious.
Also use yes_str and no_str in print_debug_abbrev_section
and print_form_data.
Signed-off-by: Mark Wielaard
---
src/ChangeLog | 6 ++
src/readelf.c | 6 +++---
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git
The afl fuzzer found a case where we tried reading an uleb for the DIE
abbrev code without properly checking the DIE address is inside the CU.
Signed-off-by: Mark Wielaard
---
libdw/ChangeLog | 4
libdw/libdwP.h | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/libdw/Ch
When interning a CU make sure that address_size and offset_size are
either 4 or 8 bytes. We really don't (want to) handle any other size.
Signed-off-by: Mark Wielaard
---
libdw/ChangeLog | 6 ++
libdw/libdw_findcu.c | 13 +++--
2 files changed, 17 insertions(+), 2 deletions(-)
On Mon, Jun 04, 2018 at 07:05:16PM +0200, Mark Wielaard wrote:
> Since we are single threaded we can just use a static result buffer for
> format_dwarf_addr as long as we make sure to print the result before
> calling format_dwarf_addr again. This removes lots of malloc/free calls.
Almost as soon
We don't really need to setup a buffer, print into it and then print it
out to stdout. Simplify the code by directly printing the address (and
symbol name).
Signed-off-by: Mark Wielaard
---
src/ChangeLog| 20 +++
src/readelf.c| 423 +--
On Thu, Jun 07, 2018 at 03:59:22PM +0200, Laurent Stacul wrote:
> Understood.
>
> In this case, there are 2 solutions:
>
> - we completely remove the call to dlopen
> - we keep the call to dlopen from the shared lib version of libdw and
> embed all the backends code in the archive
>
> I don't kn
