johan.hattne@embl-hamburg.de said:
> Static binary attached.
(which is almost identical to "t0" from Miles Nordin)

Thanks - this looks like a toolchain problem, either
the assembler or the linker.
Binutils was updated in -current after the 3.x branch.

The problem appears to be that the exception handling
information located in the ".eh_frame" section, and pointed
to by "__EH_FRAME_BEGIN__" is damaged.

On my -current system, the assembler input looks so:
        .weak   pthread_create
        .section        .eh_frame,"a",@progbits
$Lframe1:
        .4byte  $LECIE1-$LSCIE1
$LSCIE1:
        .4byte  0x0
        .byte   0x1
        .ascii "zPLR\0"

and the output:
zel637: {47} objdump -j .eh_frame -s throw.o

throw.o:     file format elf64-alpha

Contents of section .eh_frame:
 0000 1c000000 00000000 017a504c 52000178  .........zPLR..x
[...]

The linker makes __EH_FRAME_BEGIN__ point to this:
zel637: {59} gdb a.out
[...]
(gdb) x/3x &__EH_FRAME_BEGIN__
0x120060080 <__EH_FRAME_BEGIN__>: 0x0000001c 0x00000000 0x4c507a01

So far so good.

Your binaries are different:
zel637: {50} gdb t0
[...]
(gdb) x/4x &__EH_FRAME_BEGIN__
0x12009da84 <__EH_FRAME_BEGIN__>: 0x00000000 0x0000001c 0x00000000 0x4c507a01

Note the extra "0" as first entry -- this causes that the
data are not accepted by __register_frame_info (which is called
in early startup), and thus no unwind information is available
later when the exception is thrown.

I can't tell yet whether the assembler or the linker is to blame,
but you might find out by looking at the intermediate .s and .o
files as I did.

best regards
Matthias