We might already have allocated memory to hold the build_id early in
consider_notes when we called consider_phdr for the program headers
we've read from the image. We would leak that memory when we don't use
it then because we return early/fail. This can be because either we
didn't find the correct
On Mon, 2013-12-23 at 18:53 +0100, Jan Kratochvil wrote:
> > Updated patch attached.
>
> Fine with that with the comments below.
Pushed to master with the comments fixed.
> > +static int
> > +get_one_thread_cb (Dwfl_Thread *thread, void *arg)
> > +{
> > + struct one_arg *oa = (struct one_arg *)
On Mon, 2013-12-23 at 15:19 +0100, Jan Kratochvil wrote:
> On Sat, 21 Dec 2013 21:56:35 +0100, Mark Wielaard wrote:
> > On PPC64 there are two DWARF registers numbers that can represent the
> > same register. If that register is the CIE return register then we only
> > want to set it once. The seco
On Mon, 2013-12-23 at 14:37 +0100, Jan Kratochvil wrote:
> Couldn't you post the patches to GIT branches?
Sure. All patches intended to go on master are on mjw/pending. Note that
they might still be changed, they might be rebased and they might not
actually go on master in the same order as they a
Resolving addresses to function symbol names can be expensive. Use -q
to only print addresses (use together with --build-id to process later).
Demangle names by default, but add the -r option to not demangle and
show the raw names.
Signed-off-by: Mark Wielaard
---
src/ChangeLog | 12
On Mon, 23 Dec 2013 13:54:19 +0100, Mark Wielaard wrote:
> On Sun, 2013-12-22 at 16:51 +0100, Jan Kratochvil wrote:
> > If I have PID=12000 and I do 'eu-stack -p 12001' (its thread TID) then for
> > elfutils in fact PID is 12001. So if Dwfl_Thread_Callbacks.next_thread
> > returns 12001 first we c
On Sat, 21 Dec 2013 21:56:35 +0100, Mark Wielaard wrote:
> On PPC64 there are two DWARF registers numbers that can represent the
> same register. If that register is the CIE return register then we only
> want to set it once. The second setting will confuse the unwinder.
Could you provide reproduc
On Mon, 23 Dec 2013 14:22:24 +0100, Mark Wielaard wrote:
> --- a/src/ChangeLog
> +++ b/src/ChangeLog
> @@ -1,5 +1,9 @@
> 2013-12-23 Mark Wielaard
>
> + * stack.c (main): Print pid of process or core.
> +
> +2013-12-23 Mark Wielaard
> +
> * stack.c (OPT_DEBUGINFO): New define.
>
Signed-off-by: Mark Wielaard
---
libdwfl/ChangeLog |5 +
libdwfl/linux-pid-attach.c | 21 +
src/ChangeLog |4
src/stack.c|2 ++
4 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/libdwfl/ChangeLog b/libd
On Sun, 2013-12-22 at 16:51 +0100, Jan Kratochvil wrote:
> this whole discussion is difficult without seeing how you want to use it.
> I am considering only the eu-stack case as you supplied patch for it.
eu-stack is indeed a somewhat simplistic program that just uses some of
the standard callback
A convenient format for offline processing of the backtrace.
Signed-off-by: Mark Wielaard
---
src/ChangeLog |8
src/stack.c | 31 +++
2 files changed, 35 insertions(+), 4 deletions(-)
diff --git a/src/ChangeLog b/src/ChangeLog
index d3d6807..4737d69
We were using dwfl_standard_argp but trying to add our own and substract
some options from it. dwfl_standard_argp also handles kernel, modules,
executables without state and process maps that stack doesn't support.
That made argp parsing somewhat ugly and meant our --help and --usage
didn't really
Limit the number of frames printed per thread (defaults to 64) and resolve
addresses to names, modules and source after unwinding so the thread is
only stopped for the minimum time needed to do the actual unwinding. The
thread doesn't need to wait for the lookups and printing of information.
Signe
13 matches
Mail list logo
