Bug #12474
openProvide CFI for amd64 _start
0%
Description
Trying to build libunwind on illumos revealed a number of failing tests. For 64-bit applications, libunwind uses the .eh_frame and .eh_frame_hdr data to walk stacks. Looking at some of the failing tests, at least some of them are because as it walks up the stack, it goes off into the weeds because it reaches _start which does not contain any call frame information.
The AMD Sys V ABI specification for stack unwinding tends to fallback to 'whatever DWARF says' for details not specified in there. DWARF 6.4.4 says
10 If a Return Address register is defined in the virtual unwind table, and its rule is
11 undefined (for example, by DW_CFA_undefined), then there is no return address
12 and no call address, and the virtual unwind of stack activations is complete.
suggesting we should probably have some sort of .eh_frame data to indicate a successful termination of a stack walk. The native illumos tools always use frame pointers, so they don't encounter this issue, but non-native tools may encounter similar problems as libunwind.
Testing libunwind with a modified crt1.o that includes the necessary CFI directives to indicate 'end of stack' successfully stops it from going into the weeds. Aside from a few extra bytes in crt1.o, it seems fairly low risk to add this (and arguably is required by the amd64 ABI).
Updated by Jason King about 2 years ago
For a bit of reference, glibc includes .cfi_undefined %rip
in it's amd64 start.S, so we wouldn't be doing anything too radical either.
Updated by Jason King about 2 years ago
Since you seemed skeptical about the entire bug, it didn't seem worthwhile to post a review with the fix until some consensus was reached over if we consider it a legitimate bug or not.
We were at least able to get libunwind patched to work around this for illumos.