[Bug libdw/21330] New: dwarf_peel_type() loops infinitely for typedef const struct ...

https://sourceware.org/bugzilla/show_bug.cgi?id=21330 Bug ID: 21330 Summary: dwarf_peel_type() loops infinitely for typedef const struct ... Product: elfutils Version: unspecified Status: UNCONFIRMED Severity: n

Re: dwfl_attach_state alternative taking Ebl?

On Mittwoch, 29. März 2017 21:48:08 CEST Mark Wielaard wrote: > Hi Milian, > > On Wed, 2017-03-29 at 16:50 +0200, Milian Wolff wrote: > > would you be willing to accept a patch that adds an alternative to > > dwfl_attach_state taking an Ebl pointer instead of the Elf* to guess the > > architecture

Re: [RFC] libdw: prepend current directory in read_srclines

Hi Mark, > Am 27.03.2017 um 22:45 schrieb Mark Wielaard : > > Hi Torsten, > > On Sun, Mar 26, 2017 at 08:35:50PM +0200, Torsten Polle wrote: >> I observed that readelf and elfutils sometimes report different results. > > Do you have an example of this? It would be good to have a testcase. > >>

Re: dwfl_attach_state alternative taking Ebl?

Hi Milian, On Wed, 2017-03-29 at 16:50 +0200, Milian Wolff wrote: > would you be willing to accept a patch that adds an alternative to > dwfl_attach_state taking an Ebl pointer instead of the Elf* to guess the > architecture from? I rather not expose an Ebl handle to the public interface. It is

dwfl_attach_state alternative taking Ebl?

Hey all, would you be willing to accept a patch that adds an alternative to dwfl_attach_state taking an Ebl pointer instead of the Elf* to guess the architecture from? This would simplify the code for cases where we know the architecture, but don't necessarily have a corresponding Elf* at hand