mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Cc: musl@lists.openwall.com
Subject: Re: How to handle attempts to combine ARM Thumb with frame pointers?
Date: Thu, 26 Oct 2017 20:30:10 -0400	[thread overview]
Message-ID: <20171027003010.GC1627@brightrain.aerifal.cx> (raw)
In-Reply-To: <e6f4c480-c4a5-11a8-b973-226c404199da@linaro.org>

On Thu, Oct 26, 2017 at 04:46:04PM -0200, Adhemerval Zanella wrote:
> >>> http://sourceware.org/git/?p=glibc.git;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.

Rich


  reply	other threads:[~2017-10-27  0:30 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-07  0:53 Andre McCurdy
2017-10-07  1:24 ` Khem Raj
2017-10-07  1:41 ` Andre McCurdy
2017-10-08  3:21 ` Rich Felker
2017-10-09 16:48   ` Andre McCurdy
2017-10-25 21:16     ` Szabolcs Nagy
2017-10-26 16:48       ` Adhemerval Zanella
2017-10-26 17:00         ` Rich Felker
2017-10-26 17:48           ` Andre McCurdy
2017-10-26 17:54             ` Rich Felker
2017-10-26 18:51               ` Andre McCurdy
2017-10-27  0:33                 ` Rich Felker
2017-10-27  2:17                   ` Andre McCurdy
2017-10-28  0:48                     ` Andre McCurdy
2017-10-26 18:46           ` Adhemerval Zanella
2017-10-27  0:30             ` Rich Felker [this message]
2017-10-27 11:47             ` Szabolcs Nagy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171027003010.GC1627@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=adhemerval.zanella@linaro.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).