mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: [PATCH 2/2] add powerpc64 port
Date: Sun, 3 Apr 2016 13:26:31 -0400	[thread overview]
Message-ID: <20160403172631.GF21636@brightrain.aerifal.cx> (raw)
In-Reply-To: <20160403171044.GA11491@gordon.members.linode.com>

On Sun, Apr 03, 2016 at 12:10:44PM -0500, Bobby Bingham wrote:
> > > r2 is call-saved when calling to the local entry point, so setjmp needs
> > > to save it.
> >
> > OK, I see how this works for local calls to setjmp. But how does the
> > linker PLT magic work for setjmp?
> >
> > After the first return, the caller's stack slot where r2 was saved
> > belongs to the caller, and the compiler can clobber it. Upon the
> 
> The ABI is very prescriptive about the layout of a stack frame.  Each
> stack frame has several slots where callees are allowed to use part of
> their caller's frame.  For example, the link register is saved to the
> caller's frame, not the callee's.
> 
> For several of these slots, the ABI explicitly documents that they may
> be used as temporary storage which should be considered call-clobbered.
> For the slot used for saving the toc pointer (r2), the ABI makes no
> mention of it being available for temporary storage.  It would be nice
> if it were more explicit here, but I believe the intent is that the
> compiler may not use this slot for any other purpose.

My concern was not that the function itself could clobber it (although
I think it would be entitled to if it's no longer live, i.e. if no
code paths remain that reference its value) but that future function
calls might clobber it. However I think they all necessarily either
don't write to this slot at all, or write the same value that was
already there, so it's probably safe without longjmp having to restore
it.

Rich


  reply	other threads:[~2016-04-03 17:26 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-27 21:20 [RFC] " Bobby Bingham
2016-03-27 21:20 ` [PATCH 1/2] add 64bit atomics on top of 64bit ll/sc primitives Bobby Bingham
2016-03-27 22:27   ` Rich Felker
2016-03-27 21:20 ` [PATCH 2/2] add powerpc64 port Bobby Bingham
2016-03-27 23:37   ` Rich Felker
2016-03-28  0:32     ` Bobby Bingham
2016-03-28  2:18       ` Rich Felker
2016-03-28  3:27         ` Szabolcs Nagy
2016-04-02 17:02         ` Bobby Bingham
2016-04-03  2:09           ` Rich Felker
2016-04-03 17:10             ` Bobby Bingham
2016-04-03 17:26               ` Rich Felker [this message]
2016-04-03 17:50                 ` Bobby Bingham
2016-04-04  4:03         ` Bobby Bingham
2016-04-04 10:41           ` Szabolcs Nagy
2016-03-28 22:00     ` Patrick Oppenlander
2016-03-28 22:10       ` Rich Felker
2016-03-28 23:04         ` Patrick Oppenlander

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=20160403172631.GF21636@brightrain.aerifal.cx \
    --to=dalias@libc.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).