Replacing abort() with __builtin_trap()?

Hi,

When looking at Assert() failures and at PANICs, the number of "pointless"
stack entries at the top seems to have grown over the years. Here's an
example of a stacktrace (that I obviously intentionally triggered):

Program terminated with signal SIGABRT, Aborted.
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo(at)entry=6, no_tid=no_tid(at)entry=0) at ./nptl/pthread_kill.c:44
44 ./nptl/pthread_kill.c: No such file or directory.
(gdb) bt
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo(at)entry=6, no_tid=no_tid(at)entry=0) at ./nptl/pthread_kill.c:44
#1 0x00007f31920a815f in __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
#2 0x00007f319205a472 in __GI_raise (sig=sig(at)entry=6) at ../sysdeps/posix/raise.c:26
#3 0x00007f31920444b2 in __GI_abort () at ./stdlib/abort.c:79
#4 0x000055b3340c5140 in ExceptionalCondition (conditionName=0x55b3338c7ea0 "\"I kid you not\" == NULL",
fileName=0x55b3338c6958 "../../../../home/andres/src/postgresql/src/backend/tcop/postgres.c", lineNumber=4126)
at ../../../../home/andres/src/postgresql/src/backend/utils/error/assert.c:66
#5 0x000055b333ef46c4 in PostgresMain (dbname=0x55b336271608 "postgres", username=0x55b3361fa888 "andres")
at ../../../../home/andres/src/postgresql/src/backend/tcop/postgres.c:4126
#6 0x000055b333e1fadd in BackendRun (port=0x55b336267ec0) at ../../../../home/andres/src/postgresql/src/backend/postmaster/postmaster.c:4461
#7 0x000055b333e1f369 in BackendStartup (port=0x55b336267ec0) at ../../../../home/andres/src/postgresql/src/backend/postmaster/postmaster.c:4189
#8 0x000055b333e1b406 in ServerLoop () at ../../../../home/andres/src/postgresql/src/backend/postmaster/postmaster.c:1779
#9 0x000055b333e1ad17 in PostmasterMain (argc=73, argv=0x55b3361f83f0) at ../../../../home/andres/src/postgresql/src/backend/postmaster/postmaster.c:1463
#10 0x000055b333d052e2 in main (argc=73, argv=0x55b3361f83f0) at ../../../../home/andres/src/postgresql/src/backend/main/main.c:198

That's due to glibc having a very complicated abort(). Which might be nice as
a backstop, but for the default Assert it's imo just noise.

I'd like to propose that we do a configure test for __builtin_trap() and use
it, if available, before the abort() in ExceptionalCondition(). Perhaps also
for PANIC, but it's not as clear to me whether we should.

Here's a backtrace when using __builtin_trap():
#0 ExceptionalCondition (conditionName=0x55e7e7c90ea0 "\"I kid you not\" == NULL",
fileName=0x55e7e7c8f958 "../../../../home/andres/src/postgresql/src/backend/tcop/postgres.c", lineNumber=4126)
at ../../../../home/andres/src/postgresql/src/backend/utils/error/assert.c:66
66 __builtin_trap();
(gdb) bt
#0 ExceptionalCondition (conditionName=0x55e7e7c90ea0 "\"I kid you not\" == NULL",
fileName=0x55e7e7c8f958 "../../../../home/andres/src/postgresql/src/backend/tcop/postgres.c", lineNumber=4126)
at ../../../../home/andres/src/postgresql/src/backend/utils/error/assert.c:66
#1 0x000055e7e82bd6c4 in PostgresMain (dbname=0x55e7e9ea8608 "postgres", username=0x55e7e9e31888 "andres")
at ../../../../home/andres/src/postgresql/src/backend/tcop/postgres.c:4126
#2 0x000055e7e81e8add in BackendRun (port=0x55e7e9e9eec0) at ../../../../home/andres/src/postgresql/src/backend/postmaster/postmaster.c:4461
#3 0x000055e7e81e8369 in BackendStartup (port=0x55e7e9e9eec0) at ../../../../home/andres/src/postgresql/src/backend/postmaster/postmaster.c:4189
#4 0x000055e7e81e4406 in ServerLoop () at ../../../../home/andres/src/postgresql/src/backend/postmaster/postmaster.c:1779
#5 0x000055e7e81e3d17 in PostmasterMain (argc=73, argv=0x55e7e9e2f3f0) at ../../../../home/andres/src/postgresql/src/backend/postmaster/postmaster.c:1463
#6 0x000055e7e80ce2e2 in main (argc=73, argv=0x55e7e9e2f3f0) at ../../../../home/andres/src/postgresql/src/backend/main/main.c:198

Maybe I crash things too often, but I like to not have to deal with 4
pointless frames at the top...

Greetings,

Andres Freund