[PATCH] libdw: Don't free uninitialized Dwarf_Abbrev_Hash's of "fake" CUs.

2019-10-30 Thread Jonathon Anderson
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

Re: [PATCH 5/5] libdwfl: add interface for evaluating DWARF expressions in a frame

2019-10-30 Thread Omar Sandoval
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

Re: [PATCH 4/5] libdwfl: cache Dwfl_Module and Dwarf_Frame for Dwfl_Frame

2019-10-30 Thread Omar Sandoval
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

Re: [PATCH 3/5] libdwfl: add interface for attaching to/detaching from threads

2019-10-30 Thread Omar Sandoval
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 > >

Re: patch 0/2 debuginfod submission

2019-10-30 Thread Frank Ch. Eigler
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.

Re: patch 0/2 debuginfod submission

2019-10-30 Thread Mark Wielaard
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 > >

Re: patch 0/2 debuginfod submission

2019-10-30 Thread Frank Ch. Eigler
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

Re: [PATCH 5/5] libdwfl: add interface for evaluating DWARF expressions in a frame

2019-10-30 Thread Mark Wielaard
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

Re: [PATCH 4/5] libdwfl: cache Dwfl_Module and Dwarf_Frame for Dwfl_Frame

2019-10-30 Thread Mark Wielaard
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

Re: [PATCH 3/5] libdwfl: add interface for attaching to/detaching from threads

2019-10-30 Thread Mark Wielaard
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

Re: patch 0/2 debuginfod submission

2019-10-30 Thread Mark Wielaard
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