On 04/24/2017 04:53 PM, Mark Wielaard wrote:
> I got these separately. I assume they are as in the email you sent on
> Mon, 10 Apr 2017 14:48:06 +0200 (which didn't hit the list because it
> had the binaries attached...)
Yes. Those are the right binaries.
> This description doesn't seem to match
On Thu, 2017-04-20 at 11:26 +0200, Ulf Hermann wrote:
> The x86_64 case already works with the test case I sent. Maybe we can
> accept that one before the others. The aarch64 case almost works, but
> seems to generally duplicate the first entry it unwinds by frame
> pointer after unwinding anything
Add a simple i386_unwind.c frame pointer unwinder as fallback if DWARF/CFI
unwinding fails.
Signed-off-by: Mark Wielaard
---
backends/ChangeLog | 6 +++
backends/Makefile.am| 2 +-
backends/i386_init.c| 3 +-
backends/i386_unwind.c
This reverts commit f9971cb422df39adea7e8c7e22689b879e39c626.
Allowing no symbol resolving at all makes it too hard to see
whether the test actually tests anything.
But do keep "address out of range" as allowed error in check_err.
This can be interpreted as DWARF not available (if end of callstac
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
Add a check to check_core to make sure the backtracegen function is
found in the backtrace. This function is in the middle of the backtrace
in the main executable and if not found it means the backtrace was
incomplete or the frame was skipped (which could happen on a bad frame
pointer only unwind).
On 04/25/2017 02:49 PM, Mark Wielaard wrote:
> This reverts commit f9971cb422df39adea7e8c7e22689b879e39c626.
>
> Allowing no symbol resolving at all makes it too hard to see
> whether the test actually tests anything.
> [...]
Looks good to me.
Ulf
On 04/25/2017 02:49 PM, Mark Wielaard wrote:
> Add a check to check_core to make sure the backtracegen function is
> found in the backtrace. This function is in the middle of the backtrace
> in the main executable and if not found it means the backtrace was
> incomplete or the frame was skipped (wh
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
On 04/25/2017 02:49 PM, Mark Wielaard wrote:
> Add a simple i386_unwind.c frame pointer unwinder as fallback if DWARF/CFI
> unwinding fails.
Looks good to me. The logic could be relaxed a bit so that failure to e.g.
write the new value for sp would not be fatal. Then we might be able to unwind
e
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
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
> 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 Thu, Apr 20, 2017 at 04:45:51PM +0200, Ulf Hermann wrote:
> The bad fts not only needs to be included before config.h, but also
> requires various special types without including sys/types.h.
>
> Change-Id: I31ac8d2aadcf7ffb3efb63583b2745991bfd6f90
> Signed-off-by: Ulf Hermann
Thanks pushed t
On Thu, Apr 20, 2017 at 03:37:04PM +0200, Ulf Hermann wrote:
> We only include them where we actually need them and only on linux.
Looks correct. Quickly tested on Fedora and RHEL x86_64.
But I believe the other arches are correct too.
Pushed to master.
Thanks,
Mark
On Thu, Apr 20, 2017 at 03:40:46PM +0200, Ulf Hermann wrote:
> Not all search.h declare it, and it is not very helpful anyway.
Well, it is less typing and it kept the lines under 80 chars.
But because there were other longer lines already I just kept it.
Pushed to master.
Thanks,
Mark
On Thu, Apr 20, 2017 at 03:47:49PM +0200, Ulf Hermann wrote:
> Those are deprecated and apparently some implementations of nl_langinfo
> return empty strings for them. The tests even tested for those empty
> strings even though the intention of the code was clearly to output
> "yes" or "no" there.
18 matches
Mail list logo
