Provide a Breakpad API to register JIT code pages

RESOLVED WONTFIX

Status

()

Toolkit
Crash Reporting
RESOLVED WONTFIX
7 years ago
7 years ago

People

(Reporter: ted, Unassigned)

Tracking

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

7 years ago
Currently Breakpad doesn't have any info about dynamically generated JIT code pages, so when JIT code is on the stack it's forced to resort to stack scanning to find return addresses. This can make for bad times (see bug 601312). I was thinking that we should provide an API to register JIT code pages and their respective caller functions, so that when Breakpad is unwinding a stack, if it finds an instruction pointer in one of those pages, it can assume that the caller is what was provided. Does that sounds reasonable?

Something like:
RegisterJITPage(page address, caller function)
UnregisterJITPage(page address)
(Reporter)

Comment 1

7 years ago
Jim and I were chatting on IRC and I threw out what sounded like a crazy idea, but now seems eminently workable. Given the API I implemented in bug 603592, we could add some hooks to the JS engine to register all of our JIT code pages with Breakpad. We would register them with a hard-coded UUID per-JM ABI. Then they would effectively show up as modules in the minidump. Then, we hand-craft a symbol file per-JM ABI that has one fake function that covers a large address range and has a CFI rule that knows how to unwind a JM frame. (dvander says that JM frames have a frame pointer, so this should be reasonaly easy.)
Depends on: 603592
(Reporter)

Updated

7 years ago
Depends on: 606271
(Reporter)

Comment 2

7 years ago
As discussed in bug 606271, we should just make the x86-64 stackwalker know how to follow framepointers in rbp...
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.