On Fri, Nov 22, 2024 at 4:28 PM <jann...@gnu.org> wrote:
> using the (amazing) command-line that glibc creates
>
> --8<---------------cut here---------------start------------->8---
> $ x86_64-pc-gnu-gcc ../sysdeps/mach/hurd/x86_64/sigreturn.c -c -std=gnu11
> -fgnu89-inline -g -O2 -Wall -Wwrite-strings -Wundef -fmerge-all-constants
> -frounding-math -fno-stack-protector -fno-common -Wp,-U_FORTIFY_SOURCE
> -Wno-parentheses -Wstrict-prototypes -Wold-style-definition -fmath-errno
> -fPIE -fno-stack-protector -DSTACK_PROTECTOR_LEVEL=0
> -ftls-model=initial-exec -I../include
> -I/tmp/guix-build-glibc-cross-x86_64-pc-gnu-2.39.drv-0/build/signal
> -I/tmp/guix-build-glibc-cross-x86_64-pc-gnu-2.39.drv-0/build
> -I../sysdeps/mach/hurd/x86_64 -I../sysdeps/mach/hurd/x86
> -I../sysdeps/mach/hurd/x86_64/htl -I../sysdeps/mach/hurd/htl
> -I../sysdeps/hurd/htl -I../sysdeps/mach/htl -I../sysdeps/htl/include
> -I../sysdeps/htl -I../sysdeps/pthread -I../sysdeps/x86_64/htl
> -I../sysdeps/x86/htl -I../sysdeps/mach/hurd -I../sysdeps/gnu
> -I../sysdeps/unix/bsd -I../sysdeps/unix/inet -I../sysdeps/mach/x86_64
> -I../sysdeps/mach/x86 -I../sysdeps/mach/include -I../sysdeps/mach
> -I../sysdeps/x86_64/64 -I../sysdeps/x86_64/fpu/multiarch
> -I../sysdeps/x86_64/fpu -I../sysdeps/x86/fpu -I../sysdeps/x86_64/multiarch
> -I../sysdeps/x86_64 -I../sysdeps/x86/include -I../sysdeps/x86
> -I../sysdeps/ieee754/float128 -I../sysdeps/ieee754/ldbl-96/include
> -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64
> -I../sysdeps/ieee754/flt-32 -I../sysdeps/hurd/include -I../sysdeps/hurd
> -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/wordsize-64
> -I../sysdeps/ieee754 -I../sysdeps/generic -I../hurd
> -I/tmp/guix-build-glibc-cross-x86_64-pc-gnu-2.39.drv-0/build/hurd/ -I../mach
> -I/tmp/guix-build-glibc-cross-x86_64-pc-gnu-2.39.drv-0/build/mach/ -I..
> -I../libio -I. -nostdinc -isystem
> /gnu/store/6nfg25y6hfp8mx7j1cwq995mcm0kf6hw-gcc-cross-sans-libc-x86_64-pc-gnu-14.2.0-lib/lib/gcc/x86_64-pc-gnu/14.2.0/include
> -isystem
> /gnu/store/6nfg25y6hfp8mx7j1cwq995mcm0kf6hw-gcc-cross-sans-libc-x86_64-pc-gnu-14.2.0-lib/lib/gcc/x86_64-pc-gnu/14.2.0/include-fixed
> -isystem
> /gnu/store/axql682fcn94kkdyqgy1vv9pcx7n24zv-hurd-core-headers-cross-x86_64-pc-gnu-0.9.git20240714/include
> -D_LIBC_REENTRANT -include
> /tmp/guix-build-glibc-cross-x86_64-pc-gnu-2.39.drv-0/build/libc-modules.h
> -DMODULE_NAME=libc -include ../include/libc-symbols.h -DPIC
> -DTOP_NAMESPACE=glibc -o
> /tmp/guix-build-glibc-cross-x86_64-pc-gnu-2.39.drv-0/build/signal/sigreturn.o
You could now make use of this command line to see exactly how the
preprocessor expands all the macros, by replacing -c with -E and -o
.../build/signal/sigreturn.o with, say, /tmp/sigreturn.c.pp
> eh...hmm? Last thing I tried was marking the THREAD_SETMEM calls with
> NOPS
>
> reply_port = THREAD_GETMEM (THREAD_SELF, reply_port);
> asm ("nop");
> THREAD_SETMEM (THREAD_SELF, reply_port, MACH_PORT_DEAD);
> asm ("nop"); asm ("nop");
> if (__glibc_likely (MACH_PORT_VALID (reply_port)))
> (void) __mach_port_mod_refs (__mach_task_self (), reply_port,
> MACH_PORT_RIGHT_RECEIVE, -1);
> asm ("nop"); asm ("nop"); asm ("nop");
> THREAD_SETMEM (THREAD_SELF, reply_port, sc_reply_port);
> asm ("nop"); asm ("nop"); asm ("nop"); asm ("nop");
FWIW, an asm statement that's not marked as 'volatile' and doesn't
have useful outputs can be eliminated by the compiler, but it doesn't
seem to have happened here.
> and I have attached the the objdump --reloc of this. Can you make
> anything of this?
This version does seem to set reply_port:
1: 89 d5 mov %edx,%ebp
<snip>
47: 90 nop
48: 90 nop
49: 90 nop
4a: 64 89 2c 25 80 00 00 mov %ebp,%fs:0x80
51: 00
52: 90 nop
53: 90 nop
54: 90 nop
55: 90 nop
Perhaps the nops tickled the compiler a different way, and it chose
not to mis-optimize? Does this version of sigreturn.o work?
See also: [0]; if this is indeed the same bug and you can reproduce it
with just THREAD_SETMEM (and not THREAD_SELF->smth), it's a lot more
serious than I thought.
[0]
https://inbox.sourceware.org/libc-alpha/CAN9u=Heeem3L5ybS8CPHLWubFn_=1ucsn7affyzhp1-zmsg...@mail.gmail.com/T/
Sergey
