Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 26 Oct 2017 20:30:10 -0400
From: Rich Felker <>
To: Adhemerval Zanella <>
Subject: Re: How to handle attempts to combine ARM Thumb with frame

On Thu, Oct 26, 2017 at 04:46:04PM -0200, Adhemerval Zanella wrote:
> >>>;a=blob;f=sysdeps/unix/sysv/linux/arm/sysdep.h;h=6a64351cdd87c2041d639a17efc9f681262d5e3f;hb=HEAD#l335
> >>>
> >>
> >> Why do you mean by glibc strategy might not be acceptable? What
> >> kind of issue are you referring on interrupt case?
> > 
> > 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.

In that case, it might make sense to add debug or runtime unwind
information to pure asm functions that clobber the frame pointer,
which would basically just be __syscall I think. But this is a
separate topic from fixing the build issue at hand.


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.