Dwarf-Based mostly Stack Strolling The utilization of eBPF

This characteristic became beforehand launched in the announcement put up.

Sampling CPU profilers periodically salvage the stacks of the profiled processes that are running on the CPU at a given time. Strolling the stacks of native processes, reminiscent of the ones written in C, C++, Rust, and so on will seemingly be a bit more complex than one would maybe ask. Lots of the complexity is ensuing from the dearth of physique pointers, which is somewhat general.

We maintain got developed an improved stack walker that works although physique pointers are neglected in the Parca valid profiling project‘s Agent.

The stack in x86_64

The x86_64 architecture, moreover describing its instruction predicament and several varied main traits, additionally defines the foundations on how data desires to be specified by its Utility Binary Interface or ABI for transient. The specification displays how the stack desires to be predicament up for this architecture.

When this code is executed, the loads of call directions will push the return handle to the stack. As soon as a feature returns, the CPU will read the return handle and soar to it, persevering with where the callsite of the feature left.

Without a extra data, it’s no longer imaginable to reliably plot a stacktrace. There will seemingly be varied values, reminiscent of feature native data, that are kept in the stack that could perchance gaze like feature addresses. Right here’s what physique pointers purpose to resolve.

Can I really maintain a (physique) pointer?

For the next pseudocode, assuming no compiler optimisations:

int top(void) {

for(;;) { }


int c1(void) {



int b1(void) {



int a1(void) {



int main(void) {



To hunch the stack with this procedure, we need to motivate a pointer to the earlier physique. Within the x86 architecture, this often will seemingly be in the physique pointer, $rbp. As capabilities would maybe call varied capabilities, this register has to be kept on feature entry and restored on feature exit.

Right here’s done by the so-known as feature prologue, on feature entry, which would maybe gaze like this

push $rbp # saves the stack frame pointer

mov $rbp, $rsp # sets the current stack pointer to the frame pointer

And the feature epilogue on the feature returns

pop $rbp # restores the function's frame pointer

ret # pops the saved return address and jumps to it

If we collect and speed the C code above with physique pointers, the stack would maintain the total significant data to hunch the stack. Calling the loads of capabilities effectively creates a linked list that we need to traverse.

Disassembly of the code above compiled with physique pointers

# compiled with `gcc sample.c -o sample_with_frame_pointers -fno-omit-frame-pointer`

$ objdump -d ./sample_with_frame_pointers

0000000000401106 :

401106: 55 push %rbp

401107: 48 89 e5 mov %rsp,%rbp

40110a: eb fe jmp 40110a

000000000040110c :

40110c: 55 push %rbp

40110d: 48 89 e5 mov %rsp,%rbp

401110: e8 f1 ff ff ff call 401106

401115: 90 nop

401116: 5d pop %rbp

401117: c3 ret

0000000000401118 :

401118: 55 push %rbp

401119: 48 89 e5 mov %rsp,%rbp

40111c: e8 eb ff ff ff call 40110c

401121: 90 nop

401122: 5d pop %rbp

401123: c3 ret

0000000000401124 :

401124: 55 push %rbp

401125: 48 89 e5 mov %rsp,%rbp

401128: e8 eb ff ff ff call 401118

40112d: 90 nop

40112e: 5d pop %rbp

40112f: c3 ret



401130: 55 push %rbp

401131: 48 89 e5 mov %rsp,%rbp

401134: e8 eb ff ff ff call 401124

401139: b8 00 00 00 00 mov $0x0,%eax

40113e: 5d pop %rbp

40113f: c3 ret

The contents of the native stack in the instance code above when the discontinue feature is running. Shows the loads of return addresses, interleaved with the saved physique pointers. There isn't any native variables which were pushed into the stack.The contents of the native stack in the instance code above compiled with physique pointers when the discontinue feature is running.

To hunch the stack, we’d need to agree to the generated linked list above, reading the values pushed before every saved $rbpwhich is ready to manufacture our stack frames, except $rbp is zero, which indicated that we’ve reached the discontinue of the stack.

Right here’s nice because it permits us to determine the stack ticket cheaply. It’s additionally somewhat straightforward for compiler implementers so to add, and assuredly, requires a fairly minute quantity of surrounding infrastructure to manufacture it work.

Despite the total advantages, somewhat a few the code that we rely on is no longer compiled with physique pointers. Many of us rely on our Linux distribution applications and libraries, and the overwhelming majority of them plot shut to leave out physique pointers. Even at the same time as you happen to assemble your code with physique pointers, dynamically or statically linking any library equipped by your distribution would maybe prevent you from being ready to because it would be unwind the stack the employ of physique pointers on my own.

We won’t dive into the causes why physique pointers are disabled in some environments and the nuances around them, but we judge that benchmarking their overhead has to be executed on an utility-by-utility foundation. The assuredly-misplaced sight of costs that delay with disabling physique pointers would maybe quiet additionally be regarded as.

The disassemble of this executable compiled without physique pointers

# compiled with `gcc sample.c -o sample_without_frame_pointers -fomit-frame-pointer`

$ objdump -d ./sample_without_frame_pointers


0000000000401106 :

401106: eb fe jmp 401106

0000000000401108 :

401108: e8 f9 ff ff ff call 401106

40110d: 90 nop

40110e: c3 ret

000000000040110f :

40110f: e8 f4 ff ff ff call 401108

401114: 90 nop

401115: c3 ret

0000000000401116 :

401116: e8 f4 ff ff ff call 40110f

40111b: 90 nop

40111c: c3 ret



40111d: e8 f4 ff ff ff call 401116

401122: b8 00 00 00 00 mov $0x0,%eax

401127: c3 ret


Diff between the 2 disassembles


- push %rbp

- mov %rsp,%rbp

jmp 40110a


- push %rbp

- mov %rsp,%rbp

call 401106


- pop %rbp



- push %rbp

- mov %rsp,%rbp

call 40110c


- pop %rbp



- push %rbp

- mov %rsp,%rbp

call 401118


- pop %rbp



- push %rbp

- mov %rsp,%rbp

call 401124

mov $0x0,%eax

- pop %rbp


If when we’re profiling we’re somewhere in the execution of c1, the stack would maybe gaze like this:

The contents of the native stack in the instance code above when executing the discontinue feature is running. Shows the loads of return addresses, and nothing else, as there's no physique pointers nor native variables.The contents of the native stack from the code above when prime is running.

We need some varied data or hardware give a select to with a thought to reliably unwind the stack.

Hardware approaches

There are some hardware companies that we would maybe employ for stack unwinding, reminiscent of Intel’s Last Division Tale (LBR). LBR produces pairs of origin and destination addresses, FROM_IP and TO_IPthat we can employ to create stack traces. One downside they’ve is that the depth of the records they can plot is limited. Relying on the processor this could perchance also be around 32 closing taken branches.

Whereas LBR is versatile and robust, we decided to no longer employ it for CPU profiling as this characteristic is no longer in the market in every virtualized atmosphere and it’s Intel-particular. These drawbacks delay to varied gripping seller-particular processor substances, reminiscent of Intel Processor Hint (PT).

An unprecedented come across

Some of that you’ll seemingly be pondering, how is it imaginable that I’m in a position to assemble, let’s express, C++ applications without physique pointers, and exceptions quiet work right sexy? What about Rust, where physique pointers are disabled by default but invoking panic()s displays a corpulent and right stack ticket?

For C++ exceptions to work no matter how the binaries are compiled, along with so to add some varied significant companies to manufacture them feature, compilers can emit some metadata that indicated unwind the stack. This data supplies a mapping of program counters to the directions on restore the total registers.

All that is described in two documents, the DWARF debugging data format and the x86_64 ABI.

DWARF’s Call Physique Knowledge (CFI)

The first purpose of the Call Physique Knowledge is to supply solutions on restore every register for the earlier physique at any share of our code execution. Without delay storing a desk that contained every program counter and the total registers and their scheme, reminiscent of whether they’ve been pushed to the stack or no longer, would generate humongous unwind tables.

That is why, this format attempts to be compact and handiest agree with the data that’s wished. It uses varied ways to this plot reminiscent of:

  • Variable length compression of numbers with LEB128.
  • Recordsdata compression with a speak machine. Right here’s main because it permits for a extraordinarily succinct illustration of the data on the expense of elevated complexity.

The unwind tables are encoded in the CFI format in the originate of opcodes that we need to set in suggestions. There are two vital “layers” to it. The first one is a speak machine encoded in a VM. This helps with repetitive patterns that compress effectively, and permits for a more compact illustration of some data, as in some cases there’s a specialized opcode that consumes 1, 2, or 4 bytes, in desire to the employ of 4 bytes the total time. Registers that aren’t pushed into the stack would maybe no longer appear in the desk.

What I call the 2nd level, is a certain opcode that comprises one other predicament of opcodes, containing arbitrary expressions, that we need to set in suggestions. The first inequity between these two ranges is that whereas for the principle level we right desire a stack to set in suggestions and restore registers (DW_CFA_remember_state and DW_CFA_restore_staterespectively), for the 2nd level we need to set in suggestions arbitrary Turing complete expressions. That is why we desire a corpulent-blown VM to set in suggestions any expression.

Imposing a VM in BPF is no longer very good, so we decided to web a practical capacity and begin by hardcoding the 2 expressions that happen more than 50% of the times in most binaries we’ve evaluated. We maintain got some suggestions on additional toughen expression give a select to, but this weblog put up is getting procedure too long already :).

Strolling the stack the employ of DWARF’s CFI

To employ this implies to hunch the stack for a given Program Counter (PC), we need to search out its corresponding unwind data. But what can we mean by the unwind data, exactly?

We need to revive:

  • The saved return handle.
  • The values for the stack pointer ($rsp) and physique pointer ($rbp) registers in the earlier physique, which could very effectively be inclined to revive the earlier physique’s stack pointer.

The associated price of the stack pointer for the earlier physique, right before our latest feature obtained known as, in DWARF’s CFI phrases, most frequently known as the Canonical Physique Handle or CFA. As we seen before, in x86_64, the saved return handle is continually 8 bytes (a be aware) forward of the CFA.

The unwinding algorithm appears to be something like this:

  1. Be taught the preliminary registers
    1. The instruction pointer $rip. Wished to search out the row in the unwind desk.
    2. The stack pointer $rspand the physique pointer $rbpwhich could very effectively be wished to calculate the the earlier physique’s stack pointer cost (CFA). We can uncover the return handle and varied registers pushed on the stack at an offset from CFA.
  2. Whereas unwind_frame_count :
    1. Salvage the unwind desk row for the PC for which i satisfies that $unwind_table[i].PC .
      1. If there's no entry for it and $rbp is zero, we maintain reached the bottom of the stack.

    2. Add instruction pointer to the stack.
    3. Calculate the earlier physique's stack pointer. This could also be based on the latest physique's $rsp or $rbpif it's no longer an expression or register without delay.
    4. Updates the registers with the calculated values for the earlier physique.
    5. Continue with the next physique. Hotfoot to 2.

Portray: for simplicity, we’re omitting some main info that our unwinder implements.

To develop this, we need to read the unwind opcodes, set in suggestions them, and generate the tables. This route of will also be somewhat dear, but it’s how it’s executed by the exception handling infrastructure in C++, among others. Because exceptions are purported to be, erm, unprecedented, these code paths would maybe quiet no longer be exercised assuredly and the overhead won’t be too high.

Right here’s additionally the case for debuggers, reminiscent of GDB, where customers can maintain to know the stack ticket here and there to realise where they’re in the execution. These employ cases are often categorised beneath offline unwinding.

Profilers are a bit varied in that and they sample the stack dozens or somewhat a few of times a 2nd. The overhead of attending to read, parse, and set in suggestions the unwind data will also be somewhat high. Whereas stack unwinders would maybe develop some caching, the total route of is quiet somewhat dear.

A key commentary in our case is that we don’t need to revive every register, we handiest need these 2 and the saved return handle. This perception permits us to plot a illustration that works better for our on-line unwinding employ case.

Conceivable implementations

The profiler we’ve developed isn’t by a long way the principle one to make employ of this methodology. Perf, the inclined Linux profiler has supported DWARF -based stack unwinding for a whereas. By leveraging PERF_SAMPLE_REGS_USER and PERF_SAMPLE_STACK_USER launched in the perf_event_open system call in Linux 3.4, it will gain the registers for the profiled processes along with a reproduction of the stack for every sample.

Whereas this implies has been confirmed to work, and we evaluated implementing our profiler equally, it has a few drawbacks we wished to motivate away from:

  • Efficiency: the kernel copies the particular person stack for every sample. It copies the particular person stack that’s currently in employbut this could perchance also be somewhat a little bit data. Assuming a extraordinarily conservative 1K per stack * 100 samples/second * 30% of the time running on CPU * 10 CPUs=300KB per 2nd.
  • Security: the implications of getting one other route of having the values of 1 other route of’s stack will also be complex. What if some non-public key or any trend of For my fragment Identifiable Knowledge (PII) is demonstrate there?

Whereas 300KB/s doesn’t seem like somewhat a few data, we judge that this quantity will also be critically elevated for busy machines running CPU-intensive applications. We hope that by reducing the influence of the measurements whereas the profiler is running, fewer resources will seemingly be dedicated to the profiler that in every other case applications would maybe employ.

One other belief that popped into our heads became to seemingly reproduction the stack in a BPF program, but this is in a position to quiet maintain the disadvantages we wished to motivate away from, and we’d need to reimplement the functionality that the kernel already has and that it’s proved to work very effectively!

This brings us to the capacity we in a roundabout procedure took, quiet leveraging BPF!

Why BPF?

We are immense believers in BPF. There are somewhat a few causes for it. Broadly, it permits for the Linux kernel to be programmable with elevated safety ensures and a decrease barrier of entry.

Environment up profilers in BPF makes somewhat a few sense as once the stack walking mechanism is utilized, we can leverage the perf subsystem to web samples on CPU cycles, directions, L3 cache misses, or any varied performance counter that’s in the market in our machine. It additionally helps create varied instruments, reminiscent of allocation tracers, off-CPU profilers, and loads of many others.

You can seemingly seemingly be questioning, why all this talking about stack unwinding in BPF? With the bpf_get_stackid(ctx, &map, BPF_F_USER_STACK) helper we can salvage particular person stacks! Turns out, this helper walks the stack the employ of physique pointers, and a fully featured DWARF unwinder is unlikely to ever land in the kernel.

A BPF-pleasant illustration of the unwind desk

Most offline stack unwinders don’t route of most of the DWARF CFI data as they target very few program counters. Profilers, on the loads of hand, would maybe yield a elevated cardinality of program counters. That is why, and the indisputable truth that we handiest desire a subset of the data to hunch the stack, as we don’t require to know restore each register, along with to plot some illustration that minimises the work that the BPF unwinder has to develop, we decided to web on the unwind desk generation cost upfront.

In userspace, we first parse, set in suggestions, and generate unwind tables. To date, we handiest give a select to data kept in the .eh_frame ELF share. The generated desk is a few arrays built up from this row kind:

typedef struct {

u64 pc;

u16 _reserved_do_not_use;

u8 cfa_type;

u8 rbp_type;

s16 cfa_offset;

s16 rbp_offset;

} stack_unwind_row_t;

We employ a complete be aware for this scheme counter after which maintain a few fields that reduction us to calculate CFA. As an illustration, it could perchance maybe even be at an offset from both the latest $rsp or $rbp. We additionally be taught the procedure in which to revive $rbp.

The utilization of the algorithm described above, we hunch through the frames, by restoring the earlier physique’s registers. The desk is sorted by program counter, with a thought to binary search over the desk in the BPF program.

We are executed walking the stack iff we can’t uncover unwind data for a given PC and the latest $rbp is zero. We then aggregate the stacks in a BPF scheme, in kernel scheme, to maximise effectivity, and we get this data twice a minute from userspace, where we generate the profiles and ship them to a Parca Server like minded server.

The development

Early on when we started this project we realised that there were many variables that could perchance maintain an influence on its success. To the finest of our data, there’s no varied characteristic complete, initiate source, dwarf-based BPF unwinder, so we weren’t determined of how viable it would be. Hence, to maximise our potentialities of success, we tried to critically decrease the topic scheme, whereas quiet giving us as considerable signal as imaginable.

At Polar Indicators, we originate a Demand For Feedback (RFC) for every gigantic characteristic or topic we desire to discuss or web feedback on. For this work, we started with a file laying out what we wished to put for the principle iteration, including objectives and tons more importantly, the non-objectives.

After some weeks of work, we landed the first versionwhich centered on correctness. We persevered with agree to-ups to loosen the minimum kernel requirements (kernel ~4.10), along with to manufacture the unwind desk rows more compact.

Building this in BPF became an enticing project. The kernel has to be determined that any loaded program can’t fracture it. It statically analyses code the employ of the verifierwhich is ready to both reject or rep a program. One of the most latest principles as of the writing of this put up are, no dynamic allocations, termination has to be provable, and loads of others, so we needed to web ingenious to web the verifier to fair rep our program. This write-up is getting procedure too long so this could perchance also be a myth for one other time 🙂

Making an are attempting out

For the unwinder to work, every the unwind desk and the unwind algorithm utilized in BPF need to work effectively. Making certain that the tables were right became paramount in the development of this project.

On this case, we decided early on to make employ of snapshot testing in a somewhat straightforward originate. We maintain got some take a look at binaries along with the expected unwind desk in a separate git repository. As share of our testing suite in the Agent, we regenerate the tables and be determined that there aren’t any adjustments.

This methodology allowed us to mercurial iterate on the DWARF unwind data parser, helping us uncover a myriad of bugs, and saving us somewhat a few time we’d maintain spent in every other case attempting to realise why we failed at walking the stack.

Future work

There are somewhat a few substances and fixes we’re engaged on, and we’re exasperated to be sharing them with you very quickly!

We’ve handiest launched the principle version that involves dwarf-based stack unwinding a few days ago. But we already maintain some more adjustments to be determined that the profiler runs effectively in reminiscence constrained machines, improved architecture, enabling better give a select to for JIT’ed codeamong others.

Advance term, we’re shifting our center of attention in the direction of reliability, performance, and wider give a select to. The parsing, review, and handling of DWARF’s unwind data is no longer optimised but. We additionally desire to be determined that we maintain detailed performance metrics for our profiler. Finally, we desire to develop more exhaustive testing for tables produced by Clang and the Rust compiler toolchains.

The final purpose of this project is to enable this profiler by default to all of our customers, without incurring a critically elevated resource utilization.

Give it a strive!

As talked about above, this new characteristic is in the reduction of a characteristic flag, but we’re going to enable it by default in the next version when we land some improvements we’re engaged on. You can seemingly download the latest liberate here.

$ ./parca-agent [...] --experimental-enable-dwarf-unwinding


Working with the neighborhood

We judge that the pervasive lack of physique pointers is a immense topic for the utility builders, along with builders of profilers, debuggers, and compilers.

Fortuitously, this topic scheme is being actively labored on by many contributors of the broader engineering neighborhood, reminiscent of this proposal to enable physique pointers by default in Fedoraor the .ctf_frame workan different format to dwarf unwinding that’s particularly tailored to the bag, asynchronous (which implies that would maybe unwind any program counter, no longer right from particular parts) employ-case that profilers and varied instruments need.

Originate source and participating with varied communities are a immense share of our firm ethos. That’s why we started talking about this project early on, starting with a Linux Plumbers talk closing September, where we announced this work.

Our unwinder is licensed beneath the GPL license. It be initiate for inspection and contributions, and we’d take to work with varied projects facing an identical points. Don’t hesitate to attain out! Enable us to know if there’s any feedback or substances that you’ll take to gaze utilized, both in our Discord or in the GitHub discussion.


This work wouldn’t were imaginable without the work of many folk. There’s somewhat a few infrastructure that needed to be in scheme for this project to be imaginable at all.

  • The Delve debugger for Hotfoot, which our DWARF unwind data parser relies on.
  • Ian Lance Taylor’s weblog series on .eh_frame.
  • MaskRay’s weblog is packed with gripping compilers and linkers speak material.
  • The engineers all for every the DWARF requirements and varied ABIs. Environment up with something so versatile is no longer straightforward. The initiate and detailed specs are a gigantic resource.
  • Compiler engineers are the unsung heroes of this work. Creating unwind tables isn’t straightforward. Striking forward them in sync right through compiler passes is a herculean project.
  • With out BPF and its surrounding ecosystem we wouldn’t maintain a stable procedure to originate programmable system-extensive profilers. Whereas often the verifier will also be tricky, it’s our easiest ally.
  • The Legitimate and mercurial DWARF-based stack unwinding paper supplies a amazing description of the total programs we described in this put up, along with attempting some varied non-BPF approaches to speed up dwarf-based unwinders, and among the significant correctness testing they carried that found several bugs. We owe them no longer right growing the quality of unwinding tables that many programs, including ours, rely on, but additionally helped raises awareness of all these programs and how crucial they’re.

Notes and ramblings

  1. Whereas the term “stack walking” is more right in the context of profilers, and “stack unwinding” is often inclined when the runtime is handling exceptions, we employ these two phrases interchangeably.
  2. Our desk format uses the smallest datatypes we would maybe employ, which predicament some limits on the minimum and most cost for offsets, among others. You can seemingly check them out in this plot filewhich additionally involves among the significant requirements for this unwinder. We are already engaged on casting off among the significant talked about barriers!
  3. A extraordinarily gripping thought from the “Legitimate and mercurial DWARF-based stack unwinding” paper is to synthesise unwind tables from object code when unwind tables are no longer demonstrate or complete for some reason. Right here’s something we’d entertain at some point soon.
  4. To add some insights into the complexity implications, ri ght through code size, the earlier physique pointer-based unwinder will seemingly be re-utilized in BPF in no longer up to 50 traces, whereas this dwarf-based one is more than 500 traces. This excludes the total significant supporting code in userspace and assessments.
  5. Last but no longer least don’t agree with this work as an apologia for physique pointer removal! If we would maybe switch something technical and low-level in the computing industry, it could perchance maybe doubtlessly be enabling physique pointers by default. Right here’s something that hyperscalers, reminiscent of Facebook and Google already develop, no matter the aptitude additional compute prices, as they attach them headaches and time when every minute of troubleshooting an incident is costing somewhat a few cash. That being said, we take into accout that although all and sundry would agree to enable physique pointers, it could perchance maybe agree with years except all of our customers would reap the advantages.

Facet demonstrate: the C++ exception machinery is somewhat complex and has to develop somewhat a little bit work as described in this write-up. Some gripping things to evaluate: what’s going to seemingly be the associated price when the unwind tables are in reminiscence vs when they don’t seem like? Also can this be a topic with your utility? How are these paths exercised?

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top button