On Thu, 2017-04-27 at 10:31 +0200, Ulf Hermann wrote:
> > Maybe something like the attached patch?
>
> Well that's actually the original patch (as opposed to V2) with relaxed
> test conditions. You can write that a bit nicer by setting the new PC
> directly after retrieving LR and returning earl
Does every fp-only frame gets duplicated after a DWARF CFI frame?
I'll look if I can better understand why that is.
The last thing I've tested on an actual aarch64 setup is what I'm
removing in this change:
https://codereview.qt-project.org/#/c/191650/5/3rdparty/elfutils/backends/aarch64_unwi
On Thu, Apr 27, 2017 at 10:31:55AM +0200, Ulf Hermann wrote:
> > Maybe something like the attached patch?
>
> Well that's actually the original patch (as opposed to V2) with relaxed test
> conditions. You can write that a bit nicer by setting the new PC directly
> after retrieving LR and returning
Maybe something like the attached patch?
Well that's actually the original patch (as opposed to V2) with relaxed
test conditions. You can write that a bit nicer by setting the new PC
directly after retrieving LR and returning early if it doesn't work. See
"[PATCH 2/3] Add frame pointer unwind
On Wed, 2017-04-26 at 17:27 +0200, Ulf Hermann wrote:
> However, if you strip .eh_frame and .eh_frame_hdr from the exe (thus
> triggering the fp unwinding on the first frame), you will see that it
> skips sigusr2. At the same time it invents another frame 0x403f40 on
> the main thread. Apparently p
On 04/26/2017 04:33 PM, Mark Wielaard wrote:
> On Tue, 2017-04-25 at 15:38 +0200, Ulf Hermann wrote:
>>> My question is about this "initial frame". In our testcase we don't have
>>> this case since the backtrace starts in a function that has some CFI.
>>> But I assume you have some tests that rely
On Tue, 2017-04-25 at 15:38 +0200, Ulf Hermann wrote:
> > My question is about this "initial frame". In our testcase we don't have
> > this case since the backtrace starts in a function that has some CFI.
> > But I assume you have some tests that rely on this behavior.
>
> Actually the test I prov
> My question is about this "initial frame". In our testcase we don't have
> this case since the backtrace starts in a function that has some CFI.
> But I assume you have some tests that rely on this behavior.
Actually the test I provided does exercise this code. The initial
__libc_do_syscall() f
On Tue, 2017-04-25 at 14:49 +0200, Mark Wielaard wrote:
> +bool
> +EBLHOOK(unwind) (Ebl *ebl __attribute__ ((unused)), Dwarf_Addr pc
> __attribute__ ((unused)),
> + ebl_tid_registers_t *setfunc, ebl_tid_registers_get_t
> *getfunc,
> + ebl_pid_memory_read_t *readfun
On 04/25/2017 02:49 PM, Mark Wielaard wrote:
> From: Ulf Hermann
>
> If we don't find any debug information for a given frame, we usually
> cannot unwind any further. However, the binary in question might have
> been compiled with frame pointers, in which case we can look up the
> well known fram
From: Ulf Hermann
If we don't find any debug information for a given frame, we usually
cannot unwind any further. However, the binary in question might have
been compiled with frame pointers, in which case we can look up the
well known frame pointer locations in the stack snapshot and use them
to
11 matches
Mail list logo
