[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 27 Oct 2017 13:47:09 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: How to handle attempts to combine ARM Thumb with frame
pointers?
* Adhemerval Zanella <adhemerval.zanella@...aro.org> [2017-10-26 16:46:04 -0200]:
> On 26/10/2017 15:00, Rich Felker wrote:
> > If you're compiling with frame pointers because you want them to be
> > present (and always valid) for debugging purposes or similar, there's
> > no way to achieve that while making syscalls -- and the most likely
> > place for a process to get stopped debugging is usually at a syscall.
> > Maybe this doesn't matter. It's not something we can change, just an
> > observation about a problem with the ABI, I think.
>
> I think this might be a problem for musl where it does not provide
> unwind information through CFI. For debugging with GLIBC, afaik GDB
> will these information along libgcc unwind symbols to get correct call
> frame and libc-do-syscall.S does seems to have correct CFI annotations.
>
if you configure musl with --enable-debug (i.e. -g cflag) then you
get cfi annotations, but not for asm code (except on some targets
we do generate cfi for asm, but not yet on arm)
there are no runtime unwind tables though, so libgcc would not work,
however that does not work at interrupts in glibc either because arm
unwind tables are not asynchronous.
i think some tools prefer to use frame pointers for unwinding
(e.g. perf call graph profiler uses fp by default, not sure how
that works on arm thumb)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
