Project

General

Profile

Bug #12474

Provide CFI for amd64 _start

Added by Jason King 2 months ago. Updated 15 days ago.

Status:
New
Priority:
Normal
Assignee:
Category:
lib - userland libraries
Start date:
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:

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).

History

#1

Updated by Jason King 2 months 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.

#2

Updated by Rich Lowe 15 days ago

Jason, are you working on this?

#3

Updated by Jason King 15 days 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.

Also available in: Atom PDF