Closed Bug 543542 Opened 15 years ago Closed 15 years ago

Breakpad Linux Dumper: Support .eh_frame stack walking data format

Categories

(Toolkit :: Crash Reporting, defect)

Product:
Toolkit
Component:
Crash Reporting
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: jimb, Assigned: jimb)

References

Details

For exception handling, the Linux C++ ABI requires a form of stack unwinding data that is a close variant of the DWARF .debug_frame format, usually called ".eh_frame data", after the object file section it is stored in. Because the information carried in an .eh_frame section is equivalent to that that would be carried in a .debug_frame section, the GNU toolchain often does not produce a .debug_frame section if the executable would have a .eh_frame section as well: since GDB can read either format, including .debug_frame data would we a waste of space and build time. This means that, for Breakpad to support code that is compiled with exception handling enabled, it needs to also be able to parse the .eh_frame section. The .eh_frame format is described here: http://refspecs.linux-foundation.org/LSB_4.0.0/LSB-Core-generic/LSB-Core-generic/dwarfext.html http://refspecs.linux-foundation.org/LSB_4.0.0/LSB-Core-generic/LSB-Core-generic/ehframechpt.html The main differences are that .eh_frame entry headers can have five new optional fields, and that addresses in FDE headers and DW_CFI_set_loc instructions can use a variety of different encodings and be relative to a variety of base addresses. These changes allow .eh_frame data to live in read-only segments even when describing position-independent code, and allow the exception run-time support to see which exceptions a given frame can handle.
<jimb> Does Firefox include any code that is compiled with exception handling enabled on Linux? * jimb needs to know whether he needs to support .eh_frame as well as .debug_frame. <bsmedberg> jimb: you should presume we do <bsmedberg> I think ctypes does <jimb> Okay. .eh_frame is not a huge variation, it's just kind of hairy. <jimb> Unit tests are my friends! <bsmedberg> modules/plugin/base/src does, apparently
I'm finding .eh_frame to be tougher going than the actual DWARF CFI. It's ill-specified; parts of it are only documented in GCC bugzilla; dumping programs like readelf have bugs. For example, see: http://sourceware.org/ml/binutils/2010-02/msg00115.html NONETHELESS! I think I have the .eh_frame parser done; I need a few more tests. Then I need to have the dumper check the .eh_frame section in addition to the real DWARF CFI (easy).
The code is written, runs, and has unit tests. I want to clean up the patches a bit before submitting them for review. http://hg.mozilla.org/users/jblandy_mozilla.com/breakpad-mq/file/887f32356430
Status: NEW → ASSIGNED
Executive summary: once these changes are landed, we can turn on -fomit-frame-pointer for Linux. Mac is still blocked on bug 517832.
Submitted to Google for review. URLs like: http://breakpad.appspot.com/59002/show 59002 - Breakpad Linux dumper: Parse the .eh_frame section. 59001 - Breakpad DWARF parser: Add support for parsing .eh_frame encoded pointer 58002 - Breakpad DWARF parser: Expand comments for ByteReader class. 58001 - Breakpad Linux dumper: Compare section names correctly.
Landed in upstream sources.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.