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
10 matches
Mail list logo
