public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
To: Daniel Cederman <cederman@gaisler.com>, libc-alpha@sourceware.org
Cc: daniel@gaisler.com, andreas@gaisler.com
Subject: Re: [PATCH] sparc: Remove unwind information from signal return stub functions
Date: Mon, 15 Jan 2024 10:41:30 -0300	[thread overview]
Message-ID: <db60e945-f345-4d24-b180-714a620829ba@linaro.org> (raw)
In-Reply-To: <20240112092628.2464455-6-cederman@gaisler.com>



On 12/01/24 06:26, Daniel Cederman wrote:
> The functions were previously written in C, but were not compiled
> with unwind information. The ENTRY/END macros includes .cfi_startproc
> and .cfi_endproc which adds unwind information. This caused the
> tests cleanup-8 and cleanup-10 in the GCC testsuite to fail.
> This patch adds a version of the ENTRY/END macros without the
> CFI instructions that can be used instead.
> 
> sigaction registers a restorer address that is located two instructions
> before the stub function. This patch adds a two instruction padding to
> avoid that the unwinder accesses the unwind information from the function
> that the linker has placed right before it in memory. This fixes an issue
> with pthread_cancel that caused tst-mutex8-static (and other tests) to fail.
> 
> This patch fixes the issues I have seen, but I am not sure if this is
> the right solution, so any feedback is welcome!
> 
> Signed-off-by: Daniel Cederman <cederman@gaisler.com>

I am not sure this is the correct fix, at least on a sparc machine I 
do not any improvements on a sparcv9 build. But do I agree that this
seems to be a wrong/missing unwind information for the signal return
stub: the tst-mutex8-static does seems be on an infinite loop in the
libgcc unwinder code.

Does it help to restore the stub to be coded in C? It seems that the
problem that lead to rewrite the stubs in assembly (b33e946fbb1659d)
is mainly caused by '-fPIE/-fpic/-fPIC' which seems to generate a
stack frame.  I see it has started with gcc 8, and I am not sure if
this is really required by sparc ABI or it is something related to
to other compiler flags we are using (I tried to use
-fno-asynchronous-unwind-tables -fno-exceptions to prevent it, but
without much success).


> ---
>  sysdeps/sparc/sysdep.h                                |  9 +++++++++
>  .../unix/sysv/linux/sparc/sparc32/sigreturn_stub.S    | 11 +++++++----
>  2 files changed, 16 insertions(+), 4 deletions(-)
> 
> diff --git a/sysdeps/sparc/sysdep.h b/sysdeps/sparc/sysdep.h
> index c00fe79fec..44a6952bff 100644
> --- a/sysdeps/sparc/sysdep.h
> +++ b/sysdeps/sparc/sysdep.h
> @@ -76,6 +76,15 @@ C_LABEL(name)				\
>  	cfi_endproc;			\
>  	.size name, . - name
>  
> +#define ENTRY_NOCFI(name)			\
> +	.align	4;			\
> +	.global	C_SYMBOL_NAME(name);	\
> +	.type	name, @function;	\
> +C_LABEL(name)
> +
> +#define END_NOCFI(name)			\
> +	.size name, . - name
> +
>  #undef LOC
>  #define LOC(name)  .L##name
>  
> diff --git a/sysdeps/unix/sysv/linux/sparc/sparc32/sigreturn_stub.S b/sysdeps/unix/sysv/linux/sparc/sparc32/sigreturn_stub.S
> index 832223f8ce..21d36c50df 100644
> --- a/sysdeps/unix/sysv/linux/sparc/sparc32/sigreturn_stub.S
> +++ b/sysdeps/unix/sysv/linux/sparc/sparc32/sigreturn_stub.S
> @@ -23,12 +23,15 @@
>  
>     [1] https://lkml.org/lkml/2016/5/27/465  */
>  
> -ENTRY (__rt_sigreturn_stub)
> +	nop
> +	nop
> +
> +ENTRY_NOCFI (__rt_sigreturn_stub)
>  	mov	__NR_rt_sigreturn, %g1
>  	ta	0x10
> -END (__rt_sigreturn_stub)
> +END_NOCFI (__rt_sigreturn_stub)
>  
> -ENTRY (__sigreturn_stub)
> +ENTRY_NOCFI (__sigreturn_stub)
>  	mov	__NR_sigreturn, %g1
>  	ta	0x10
> -END (__sigreturn_stub)
> +END_NOCFI (__sigreturn_stub)

  reply	other threads:[~2024-01-15 13:41 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-12  9:26 [PATCH] sparc: Do not test preservation of NaN payloads for LEON Daniel Cederman
2024-01-12  9:26 ` [PATCH] sparc: Prevent stfsr from directly following floating-point instruction Daniel Cederman
2024-01-12 14:38   ` Adhemerval Zanella Netto
2024-01-15  9:37     ` Daniel Cederman
2024-01-12  9:26 ` [PATCH] sparc: Force calculation that raises exception Daniel Cederman
2024-01-12 16:45   ` Adhemerval Zanella Netto
2024-01-15  9:41     ` Daniel Cederman
2024-01-15 11:47       ` Adhemerval Zanella Netto
2024-01-12  9:26 ` [PATCH] sparc: Treat the version field in the FPU control word as reserved Daniel Cederman
2024-01-12 17:42   ` Adhemerval Zanella Netto
2024-02-15  9:31     ` Daniel Cederman
2024-02-19 14:55       ` Adhemerval Zanella Netto
2024-01-12  9:26 ` [PATCH] sparc: Fix llrint and llround missing exceptions on SPARC32 Daniel Cederman
2024-01-12 18:05   ` Adhemerval Zanella Netto
2024-01-15 14:38     ` Daniel Cederman
2024-01-15 17:52       ` Adhemerval Zanella Netto
2024-01-12  9:26 ` [PATCH] sparc: Remove unwind information from signal return stub functions Daniel Cederman
2024-01-15 13:41   ` Adhemerval Zanella Netto [this message]
2024-01-15 14:22     ` Daniel Cederman
2024-01-15 16:57       ` Adhemerval Zanella Netto
2024-01-16 15:37 ` [PATCH] sparc: Do not test preservation of NaN payloads for LEON Adhemerval Zanella Netto

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=db60e945-f345-4d24-b180-714a620829ba@linaro.org \
    --to=adhemerval.zanella@linaro.org \
    --cc=andreas@gaisler.com \
    --cc=cederman@gaisler.com \
    --cc=daniel@gaisler.com \
    --cc=libc-alpha@sourceware.org \
    /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).