public inbox for libffi-discuss@sourceware.org
 help / color / mirror / Atom feed
From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: rth@redhat.com (Richard Henderson)
Cc: libffi-discuss@sourceware.org,
	Ulrich.Weigand@de.ibm.com (Ulrich Weigand),
	       krebbel@linux.vnet.ibm.com (Andreas Krebbel)
Subject: Re: [PATCH] Go closures for s390[x]
Date: Fri, 19 Dec 2014 13:13:00 -0000	[thread overview]
Message-ID: <201412191313.sBJDDb77031594@d03av02.boulder.ibm.com> (raw)
In-Reply-To: <5493471D.4020506@redhat.com> from "Richard Henderson" at Dec 18, 2014 03:29:01 PM

Richard Henderson wrote:
> On 12/16/2014 09:05 AM, Dominik Vogt wrote:
> >  	lm	%r6,%r15,48+24(%r11)
> > +	.cfi_remember_state
> > +	.cfi_restore 15
> > +	.cfi_restore 14
> > +	.cfi_restore 13
> > +	.cfi_restore 12
> > +	.cfi_restore 11
> > +	.cfi_restore 10
> > +	.cfi_restore 9
> > +	.cfi_restore 8
> > +	.cfi_restore 7
> > +	.cfi_restore 6
> > +	.cfi_def_cfa r15, 96
> >  	br	%r4
> > +	.cfi_restore_state
> > +	# This nopr is necessary so that the .cfi instructions between the br
> > +	# above and the label below get executed.  See execute_cfa_program() in
> > +	# the Gcc source code, libgcc/unwind-dw2.c.
> > +	nopr
> 
> I'm not really sure you need any of these restores, since the data is still on
> the stack, unclobbered.  I think you'd really only need to reset the cfa here.

Ah, right.  The GPRs are saved in the 96/160-byte bias area, which is not
clobbered even by signal handlers.  (I guess GCC could also do that same
optimization when creating CFI for epilogues ...)

It looks like we do need the restore of r15, though, otherwise the CFA
compuation will be wrong.

> The nopr seems like a red herring.  I don't see why the < vs <= for
> execute_cfa_program is relevant -- this is not following a call.

Actually, it sort-of is; the code does:
        la      %r14,0(%r13,%r9)                # Set return address
        br      %r7                             # ... and call function

i.e. sets the return address register to point to one of the return stubs
and then jumps to the target function instead of calling it; so from the
point of view of an unwinder, it looks like the target function was called
from the instruction immediately preceding the return stub.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com

  reply	other threads:[~2014-12-19 13:13 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-16 15:05 Dominik Vogt
2014-12-18 21:29 ` Richard Henderson
2014-12-19 13:13   ` Ulrich Weigand [this message]
2014-12-19 14:10     ` Richard Henderson
2014-12-19 14:48       ` Ulrich Weigand
2014-12-22 10:27   ` Dominik Vogt
2014-12-22 16:31     ` Richard Henderson

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=201412191313.sBJDDb77031594@d03av02.boulder.ibm.com \
    --to=uweigand@de.ibm.com \
    --cc=Ulrich.Weigand@de.ibm.com \
    --cc=krebbel@linux.vnet.ibm.com \
    --cc=libffi-discuss@sourceware.org \
    --cc=rth@redhat.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.
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 read-only IMAP folder(s) and NNTP newsgroup(s).