[Bug middle-end/56314] Please allow per-function specification of register conventions

[benh at kernel dot crashing.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56314



benh at kernel dot crashing.org changed:



   What|Removed |Added



 CC||benh at kernel dot

   ||crashing.org



--- Comment #4 from benh at kernel dot crashing.org 2013-02-15 06:52:31 UTC ---

I would definitely like to see that on powerpc as well.



A typical usage case for Linux is inline functions intended as a fast path

(such as spin lock) for which we want to be able to branch to an unlikely slow

path (contention case, timeout case, error case...) while limiting the impact

on the caller.

[Bug c/78875] New: -fstack-protector on powerpc64 now always use TLS, won't work for kernel/firmware

[benh at kernel dot crashing.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78875

Bug ID: 78875
   Summary: -fstack-protector on powerpc64 now always use TLS,
won't work for kernel/firmware
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: benh at kernel dot crashing.org
  Target Milestone: ---

Some standalone (not linked with glibc) programs such as the Linux Kernel
or the OPAL firmware do not have a TLS per-se. They use r13 for different
purposes (both examples here use it as some kind of per-cpu pointer).

Depending on gcc version and how it was built, the canary used by
-fstack-protector on powerpc64 is either loaded from a global (r2 relative) or
from the TLS (r13).

The latter case won't work for those programs. I looked into doing like x86 and
basically maintaining an equivalent of that portion of the TLS space for this,
but the offset used -0x7000 really doesn't work with either Linux or OPAL
without major changes to how they use r13.

In the meantime, it would be useful to still be able to exploit the stack
protector, to be able to force via a gcc command line option, the use of
globals instead of TLS (and in general disable any built-in access to the TLS
for projects that have a special runtime environment that doesn't use r13 for
that purpose).

[Bug testsuite/113005] 'libgomp.fortran/rwlock_1.f90', 'libgomp.fortran/rwlock_3.f90' execution test timeouts

[benh at kernel dot crashing.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113005

benh at kernel dot crashing.org changed:

   What|Removed |Added

 CC||benh at kernel dot crashing.org

--- Comment #20 from benh at kernel dot crashing.org ---
I don't know if this data point is worth it but I've been chasing a hang in
Koji when trying to build our gcc 14 that points to that test as well. It
appears that it was sporadic until recent updates to our glibc (basically c9s
glibc) which makes it happen much more often (maybe due to changes in the cond
vars implementation ? not sure...).


What I observe is that sometimes rwlock_1.ext doesn't just fail/timeout, it
actually deadlocks in what looks like a cleanup path (and stays there forever).
The build has to be killed (or ssh in the builder & kill rwlock_1.ext and the
test suite then continues).

Now when I just run that test manually (with pretty much the same libgomp &
libgfortran installed system-wide), I get a slightly different "error":

[ec2-user@ip-172-31-17-247 libgomp5]$ ./rwlock_1.exe
STOP 2
STOP 2
Internal Error: Trying to free nonempty asynchronous unit

Error termination. Backtrace:
#0  0x7f210b4d8d7e in free_async_unit
at ../../../libgfortran/io/async.c:211
#1  0x7f210b4cd429 in close_unit_1
at ../../../libgfortran/io/unit.c:759
#2  0x7f210b57109d in _dl_fini
at
/usr/src/debug/glibc-2.34-196.al2023benh.0.2.x86_64/elf/dl-fini.c:142
#3  0x7f210ae4231c in __run_exit_handlers
at
/usr/src/debug/glibc-2.34-196.al2023benh.0.2.x86_64/stdlib/exit.c:126
#4  0x7f210ae4246f in __GI_exit
at
/usr/src/debug/glibc-2.34-196.al2023benh.0.2.x86_64/stdlib/exit.c:156
#5  0x401884 in ???
#6  0x7f210b0f0b4d in gomp_thread_start
at ../../../libgomp/team.c:129
#7  0x7f210ae8b4e9 in start_thread
at
/usr/src/debug/glibc-2.34-196.al2023benh.0.2.x86_64/nptl/pthread_create.c:443
#8  0x7f210af106cf in clone3
at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
#9  0x in ???

and in gdb:

Thread 13 "rwlock_1.exe" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x709f4640 (LWP 2491931)]
__pthread_clockjoin_ex (threadid=140736011957824,
thread_return=thread_return@entry=0x0, clockid=clockid@entry=0,
abstime=abstime@entry=0x0, block=block@entry=true) at
pthread_join_common.c:43
43if (INVALID_NOT_TERMINATED_TD_P (pd))
(gdb) backtrace
#0  __pthread_clockjoin_ex (threadid=140736011957824,
thread_return=thread_return@entry=0x0, clockid=clockid@entry=0,
abstime=abstime@entry=0x0, block=block@entry=true) at
pthread_join_common.c:43
#1  0x7788ce83 in ___pthread_join (threadid=,
thread_return=thread_return@entry=0x0) at pthread_join.c:25
#2  0x77ed8d30 in __gthread_join (__threadid=,
__value_ptr=0x0) at ../libgcc/gthr-default.h:682
#3  _gfortrani_async_close (au=0x7fffbc003540) at
../../../libgfortran/io/async.c:486
#4  0x77ecd42a in close_unit_1 (u=0x7fffbc000fb0,
locked=locked@entry=1) at ../../../libgfortran/io/unit.c:759
#5  0x77ecd61a in _gfortrani_close_units () at
../../../libgfortran/io/unit.c:836
#6  0x77fcb09e in _dl_fini () at dl-fini.c:142
#7  0x7784231d in __run_exit_handlers (status=status@entry=2,
listp=0x779fa838 <__exit_funcs>,
run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true)
at exit.c:126
#8  0x77842470 in __GI_exit (status=status@entry=2) at exit.c:156
#9  0x77c25cb3 in _gfortran_stop_numeric (code=2, quiet=) at ../../../libgfortran/runtime/stop.c:126
#10 0x00401885 in MAIN__._omp_fn.0 ()
#11 0x77f88b4e in gomp_thread_start (xdata=) at
../../../libgomp/team.c:129
#12 0x7788b4ea in start_thread (arg=) at
pthread_create.c:443
#13 0x779106d0 in clone3 () at
../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
Thread 13 "rwlock_1.exe" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x709f4640 (LWP 2491931)]
__pthread_clockjoin_ex (threadid=140736011957824,
thread_return=thread_return@entry=0x0, clockid=clockid@entry=0,
abstime=abstime@entry=0x0, block=block@entry=true) at
pthread_join_common.c:43
43if (INVALID_NOT_TERMINATED_TD_P (pd))
(gdb) backtrace
#0  __pthread_clockjoin_ex (threadid=140736011957824,
thread_return=thread_return@entry=0x0, clockid=clockid@entry=0,
abstime=abstime@entry=0x0, block=block@entry=true) at
pthread_join_common.c:43
#1  0x7788ce83 in ___pthread_join (threadid=,
thread_return=thread_return@entry=0x0) at pthread_join.c:25
#2  0x77ed8d30 in __gthread_join (__threadid=,
__value_ptr=0x0) at ../libgcc/gthr-default.h:682
#3  _gfortrani_async_close (au=0x7fffbc003540) at
../../../libgfortran/io/async.c:486
#4  0x77ecd42a in close_unit_1 (u=0x7fffbc000fb0,
locked=locked@entry=1) at .

[Bug testsuite/113005] 'libgomp.fortran/rwlock_1.f90', 'libgomp.fortran/rwlock_3.f90' execution test timeouts

[benh at kernel dot crashing.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113005

--- Comment #21 from benh at kernel dot crashing.org ---
s/rwlock_1.ext/rwlock1_exe/ ... looks like my fingers refuse to type ".exe" ..
I wonder why :-)