Confused by the __restore_rt symbol

Adhemerval Zanella adhemerval.zanella@linaro.org
Tue May 22 18:58:00 GMT 2018



On 15/05/2018 23:16, Hualet Wang wrote:
> Hi there,
> 
> I'm trying to understand signal handling in linux recently, everything is
> fine by now except the so called "signal trampoline" part,  I know it's
> trying to call sigreturn,  but I'm totally confused by the  __restore_rt
> and __restore symbol:
> 
> 1. why does it appear in sigaction.c and exported by libphread ?

Both '__restore_rt' and '__restore' if required by kabi are local for both libc
and libpthread.  And sigaction is exported on libpthread mainly because it 
initially had a slight different semantic than the one exported by libc.so (it 
didn't allow SIG32/SIGCANCEL to be set).  Both libpthread and libc sigaction
are now essentially the same (libc one also does not allow caller to set nptl 
internal signals), however we still need to continue provide it through 
libpthread because of compatibility.

> 2. why __restore_rt shows up in the stacktrace if my test program (attached
> bellow) linked against libpthread and otherwise not?

I think it might a build issue with your distro libc, I am seeing something
similar to my ubuntu 16.04 installation:

$ readelf -s /lib/x86_64-linux-gnu/libc-2.23.so | grep __restore_rt
$ readelf -s /lib/x86_64-linux-gnu/libpthread-2.23.so | grep __restore_rt
    77: 0000000000011390     0 FUNC    LOCAL  DEFAULT   14 __restore_rt

However master does show both LOCAL symbol being defined in both libraries:

build/x86_64-linux-gnu$ readelf -s libc.so | grep __restore_rt
   358: 00000000000346d0     0 FUNC    LOCAL  DEFAULT   12 __restore_rt
build/x86_64-linux-gnu$ readelf -s nptl/libpthread.so | grep __restore_rt
   300: 0000000000011af0     0 FUNC    LOCAL  DEFAULT   13 __restore_rt

I can't recall any recent change which might relate to this.  I recent 
consolidate the sigaction implementation for Linux (b4a5d26d8835d9), but
I kept the rt_restore semantic unchanged.

In any case for either case the __restore_rt is indeed called though. On 
default case (not linked to libpthread), the __NR_rt_restore is indeed
issues (GDB can't only get its name due missing symbol table name):

=> x/4i $pc
=> 0x7ffff7a424b0:	mov    $0xf,%rax
   0x7ffff7a424b7:	syscall 

> 
> Please someone  shed some light on this,  that'll be much appreciated.
> 
> PS: compile the test program with `gcc -rdynamic test-sigaction.c  -o
> test-sigaction`
> 
> ========== test-sigaction.c ===========
> 
> #include <signal.h>
> #include <stddef.h>
> #include <stdio.h>
> #include <unistd.h>
> 
> #include<execinfo.h>
> 
> #define SIZE 100
> 
> void print_backtrace()
> {
>         int size;
>         void *buffer[SIZE];
> 
>         size = backtrace(buffer, SIZE);
> 
>         char** stack = backtrace_symbols(buffer, size);
>         for (int i = 0; i < size; i++) {
>                 printf("%s \n", stack[i]);
>         }
> }
> 
> 
> void
> termination_handler (int signum)
> {
> printf("here in termination handler \n");
> /*
> while(1) {
> printf("haha");
> }
> */
> print_backtrace();
> }
> 
> int
> main (void)
> {
>   struct sigaction new_action, old_action;
> 
>   /* Set up the structure to specify the new action. */
>   new_action.sa_handler = termination_handler;
>   sigemptyset (&new_action.sa_mask);
>   new_action.sa_flags = 0;
> 
>   sigaction (SIGINT, &new_action, NULL);
> 
>   while(1) {
> printf("here in the main loop \n ");
> sleep(1);
>   }
> }
> 
> 
> 




More information about the Libc-help mailing list