# sframe

Published articles for sframe.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## Stack walking: space and time trade-offs

DevFeed: [Stack walking: space and time trade-offs](<https://devfeed.tech/articles/stack-walking-space-and-time-trade-offs-31136.md>)

Original publisher: [Read original article](<https://maskray.me/blog/stack-walking-space-and-time-trade-offs>)

Published: 2025-10-26T07:00:00Z

Content type: article

Language: en

Sources: [MaskRay](<https://devfeed.tech/sources/maskray.md>)

Topics: [LLVM](<https://devfeed.tech/topics/llvm.md>), [Linux](<https://devfeed.tech/topics/linux.md>), [C++](<https://devfeed.tech/topics/c-plus-plus.md>)

Tags: [article](<https://devfeed.tech/tags/article.md>), [gcc](<https://devfeed.tech/tags/gcc.md>), [linux](<https://devfeed.tech/tags/linux.md>), [llvm](<https://devfeed.tech/tags/llvm.md>), [performance-analysis](<https://devfeed.tech/tags/performance-analysis.md>), [platforms](<https://devfeed.tech/tags/platforms.md>), [required](<https://devfeed.tech/tags/required.md>), [sframe](<https://devfeed.tech/tags/sframe.md>), [update](<https://devfeed.tech/tags/update.md>)

### AI overview

This article examines space and time trade-offs among stack-walking mechanisms on Linux, including DWARF, frame pointers, SFrame, LLVM's Compact Unwinding Format, Last Branch Record, and CET Shadow Stack. It analyzes the size overhead of enabling non-DWARF mechanisms when building LLVM executables; runtime performance analysis is deferred to a future update.

### Source excerpt

On most Linux platforms (except AArch32, which uses .ARM.exidx), DWARF .eh_frame is required for C++ exception handling and stack unwinding to restore callee-saved registers. While .eh_frame can be used for call trace recording, it is often criticized for its runtime overhead. As an alternative, developers can enable frame pointers, or adopt SFrame, a newer format designed specifically for profiling. This article examines the size overhead of enabling non-DWARF stack walking mechanisms when building several LLVM executables. Runtime performance analysis will be added in a future update.

## Remarks on SFrame

DevFeed: [Remarks on SFrame](<https://devfeed.tech/articles/remarks-on-sframe-31135.md>)

Original publisher: [Read original article](<https://maskray.me/blog/remarks-on-sframe>)

Published: 2025-09-28T07:00:00Z

Content type: article

Language: en

Sources: [MaskRay](<https://devfeed.tech/sources/maskray.md>)

Topics: [Linux](<https://devfeed.tech/topics/linux.md>), [Compiler](<https://devfeed.tech/topics/compiler.md>), [Optimization](<https://devfeed.tech/topics/optimization.md>), [x86](<https://devfeed.tech/topics/x86.md>)

Tags: [compiler](<https://devfeed.tech/tags/compiler.md>), [linker](<https://devfeed.tech/tags/linker.md>), [linux](<https://devfeed.tech/tags/linux.md>), [llvm](<https://devfeed.tech/tags/llvm.md>), [optimization](<https://devfeed.tech/tags/optimization.md>), [profiling](<https://devfeed.tech/tags/profiling.md>), [sframe](<https://devfeed.tech/tags/sframe.md>), [x86-64](<https://devfeed.tech/tags/x86-64.md>)

### AI overview

An analysis of SFrame, a stack-walking format for userspace profiling inspired by Linux's ORC unwind format. It examines SFrame's trade-offs against .eh_frame and Windows ARM64 unwind codes, its section layout, versioning, and opportunities to reduce data-structure overhead.

### Source excerpt

SFrame is a new stack walking format for userspace profiling, inspired by Linux's in-kernel ORC unwind format. While SFrame eliminates some .eh_frame CIE/FDE overhead, it sacrifices functionality (e.g., personality, LSDA, callee-saved registers) and flexibility, and its stack offsets are less compact than .eh_frame's bytecode-style CFI instructions. In llvm-project executables I've tested on x86-64, .sframe section is 20% larger than .eh_frame. It also remains significantly larger than highly compact schemes like Windows ARM64 unwind codes. SFrame describes three elements for each function: Canonical Frame Address (CFA): The base address for stack frame calculations Return address Frame pointer An .sframe section follows a straightforward layout: Header: Contains metadata and offset information Auxiliary header (optional): Reserved for future extensions Function Descriptor Entries (FDEs): Array describing each function Frame Row Entries (FREs): Arrays of unwinding information per function