On Thursday, 1 May 2025 15:00:07 Pacific Daylight Time Frederick Virchanza
Gotham via Std-Proposals wrote:
> see how the assembler changes:
>
> Func():
> push %rax
> call 6 <Func()+0x6>
> R_X86_64_PLT32 SomeOtherFunc()-0x4
> mov $0x7,%eax
> pop %rcx
> ret
> mov %rax,%rdi
> call 15 <Func()+0x15>
> R_X86_64_PLT32 __clang_call_terminate-0x4
>
> You can see that two more instructions have been tagged onto the end:

And if you try GCC, they aren't. I don't know why Clang decided to emit the
call to terminate in code, but it doesn't have to. The exception-handling
information that is not part of the code sufficiently tells the unwinder that it
should not unwind this block and should instead terminate.

g():
        .cfi_startproc
        .cfi_personality 0x3,__gxx_personality_v0
        .cfi_lsda 0x3,.LLSDA0
        subq $8, %rsp
        .cfi_def_cfa_offset 16
        call f()
        movl $7, %eax
        addq $8, %rsp
        .cfi_def_cfa_offset 8
        ret
        .cfi_endproc
        .section .gcc_except_table,"a",@progbits
.LLSDA0:
        .byte 0xff
        .byte 0xff
        .byte 0x1
        .uleb128 .LLSDACSE0-.LLSDACSB0

I don't know how to decode the .gcc_except_table section (I've never seen a
tool for that), but I can tell you it does work and that's only 4 bytes that
are not part of any hot code or data path.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel DCAI Platform & System Engineering