517825 - Breakpad Linux Dumper: document proposed call frame information format

Status: RESOLVED FIXED

(Toolkit :: Crash Reporting, defect)

Description

[Jim Blandy :jimb]

As a basis for further work, the Breakpad wiki page describing the symbol file format:

http://code.google.com/p/google-breakpad/wiki/SymbolFiles

should be extended to describe how call frame information derived from DWARF CFI should be represented in Breakpad symbol files.  Jim Blandy has ideas for a format which he described to Ted Mielczarek and Neal Sidhwaney; those ideas need to be put down in more detail.

Note that Breakpad symbol files already have "STACK WIN" records that carry Windows PDB unwinding information.  I considered whether these could effectively carry DWARF CFI as well, but it seems that they require a bunch of fields that are irrelevant to DWARF CFI.

Comment 1

[Jim Blandy :jimb]

Here's why we can't use the existing "STACK WIN" Breakpad symbol file records for recording DWARF CFI:

DWARF CFI manages to be detailed without being bulky by describing the rules for unwinding at a given machine instruction in terms of the *differences* from the rules for the prior machine instruction.  (The process bottoms out at function entry points, at which the rules are described in their entirety.)

In contrast, each STACK WIN records is self-contained.  This strategy seems to depend on irregular stack frames being rare, and seems to simply give up on unwinding from function prologues and epilogues.  DWARF tries to handle these cases properly, making the 'differences from prior' arrangement more important.

The proposed "STACK CFI" records that this bug would have me document on the wiki behave more like DWARF CFI: detailed, complete, and described in this "I-frame/D-frame" fashion.

Comment 2

[Jim Blandy :jimb]

I've put draft text up:

http://code.google.com/p/google-breakpad/wiki/SymbolFiles

Comment 3

[Jim Blandy :jimb]

Neal Sidhwaney brought up some issues to address:

http://groups.google.com/group/google-breakpad-dev/browse_thread/thread/c39eed4ed885c896

Comment 4

[Jim Blandy :jimb]

The documentation is written, and I've implemented the processor side, so I think it makes sense to close this bug, and file new issues for whatever comes up.