Bug 129178
| Summary: | REGRESSION(C stack work): stack traces no longer work in in some tools | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Michael Saboff <msaboff> |
| Component: | JavaScriptCore | Assignee: | Michael Saboff <msaboff> |
| Status: | ASSIGNED | ||
| Severity: | Normal | ||
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | All | ||
| OS: | All | ||
| Bug Depends on: | 129181, 131205, 131578 | ||
| Bug Blocks: | |||
Michael Saboff
The recent addition of callToJavaScript as the entry point into interpreted and JIT'ed code breaks unwinding in some tools. This is due to unwinding code doing some simple disassembly in order to determine where a caller's frame pointer and return PC is stored. The best way to fix this is to make callToJavaScript conform to the calling conventions using the recommended function prologue instruction sequence. For X86 that is typically push bp ; move sp, bp.
There is an additional issue with the LLInt, in that one llint_op does an indirect jump to the subsequent llint_op. Since currently each llint_op is an external symbol, the unwind library will look at the instructions at the beginning of the llint_op to find callee values.
Both of these issues can be solved by having the llint generate all assembly as one exported function. The entry to the function would conform to the standard calling convention. The entry would also will in a vector with an ordered list of entry points, what is currently LLIntData::Data::s_opcodeMap.
This work will be done via several bugs.
<rdar://problem/15713914>
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |