fake_{loc,loclists,addr}_cu are Dwarf_CUs that are created separate from
all the others, so their contents are minimal and mostly initialized by
a calloc. On dwarf_end however, they are freed through the same code path
as all the others, so they call DAH_free like all the others. This changes
that
On Wed, Oct 30, 2019 at 02:23:06PM +0100, Mark Wielaard wrote:
> Hi Omar,
>
> On Mon, 2019-10-07 at 02:05 -0700, Omar Sandoval wrote:
> > libdwfl can evaluate DWARF expressions in order to unwind the stack,
> > but this functionality isn't exposed to clients of the library. Now that
> > the pieces
On Wed, Oct 30, 2019 at 02:04:42PM +0100, Mark Wielaard wrote:
> Hi Omar,
>
> On Mon, 2019-10-07 at 02:05 -0700, Omar Sandoval wrote:
> > The next change will need to have the Dwarf_Frame readily available, so
> > rather than finding it again every time, let's cache it for reuse. The
> > CFI frame
On Wed, Oct 30, 2019 at 01:47:52PM +0100, Mark Wielaard wrote:
> Hi Omar,
>
> On Mon, 2019-10-07 at 02:05 -0700, Omar Sandoval wrote:
> > libdwfl has implementations of attaching to/detaching from threads
> > and
> > unwinding stack traces. However, that functionality is only available
> > through
Hi -
> Ah, I was not thinking that far yet. I was just worried about the
> dlopen/dlsym dance being done on every call. Which does its own file
> search to find the library. So simply setting debuginfod_so = (void *)
> -1; on first failure to make sure dlopen/dlsym it is never called
> again.
Rev
Hi Frank,
On Wed, 2019-10-30 at 09:40 -0400, Frank Ch. Eigler wrote:
> OK, sure, IMO don't even bother with a guard. It's just a dlopen/dlsym,
> which is portable. Will update the first patch on the branch with that.
Thanks.
> > Also I think you should cache a negative result for
> > fp_debugi
Hi, Mark -
> I only browsed through the code quickly, but I like what I see.
> For now just a comment on the libdwfl integration.
Righto.
> It is guarded by ENABLE_DEBUGINFOD, which is off by default.
> I think the support should always be enabled in libdwfl whether or not
> the debuginfod ser
Hi Omar,
On Mon, 2019-10-07 at 02:05 -0700, Omar Sandoval wrote:
> libdwfl can evaluate DWARF expressions in order to unwind the stack,
> but this functionality isn't exposed to clients of the library. Now that
> the pieces are in place, add dwfl_frame_eval_expr to provide this feature.
I think t
Hi Omar,
On Mon, 2019-10-07 at 02:05 -0700, Omar Sandoval wrote:
> The next change will need to have the Dwarf_Frame readily available, so
> rather than finding it again every time, let's cache it for reuse. The
> CFI frame can also be useful to clients of libdwfl, so add
> dwfl_frame_dwarf_frame
Hi Omar,
On Mon, 2019-10-07 at 02:05 -0700, Omar Sandoval wrote:
> libdwfl has implementations of attaching to/detaching from threads
> and
> unwinding stack traces. However, that functionality is only available
> through the dwfl_thread_getframes interface, which isn't very flexible.
> This adds
Hi Frank, Hi Aaron,
On Mon, 2019-10-28 at 15:04 -0400, Frank Ch. Eigler wrote:
> Aaron Merey and I would like to propose debuginfod for merge into
> elfutils mainline, after a couple of months of work. As a reminder,
> this is an http server (written in C++11) for debuginfo-related
> artifacts (e
11 matches
Mail list logo
