Dump all registers on a fault on Intel

Details

  • Type: Improvement Improvement
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: None
  • Fix Version/s: 3.2
  • Component/s: Instruction Architecture: Intel
  • Labels:
    None

Description

Currently an unhandled fault on Intel will dump out the 8 GPRs and 8 x87 registers. If using SSE2 we should dump out the XMM registers too.

Issue Links

is related to

New Feature - A new feature of the product, which has yet to be developed. RVM-35 Make unknown error and virtual machine errors more verbose

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Open - The issue is open and ready for the assignee to start work on it.
relates to

Improvement - An improvement or enhancement to an existing feature or task. RVM-162 Remove x87 code generation from opt compiler.

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Ian Rogers added a comment -

We should also sanitize the x87 register names. Currently they are called FP0 to FP7, Intel call the x87 registers ST0 (stack top) to ST7 and the SSE registers XMM0 to XMM7. We also have two special register names ST0 and ST1 used to address the x87 stack when we can't perform operations in SSE. The reason the FP name exists is that the original x87 register allocation was to treat the x87 stack as a flat register file and perform trickery with stack exchange operations (fxch) to make it appear so.

Show
Ian Rogers added a comment - We should also sanitize the x87 register names. Currently they are called FP0 to FP7, Intel call the x87 registers ST0 (stack top) to ST7 and the SSE registers XMM0 to XMM7. We also have two special register names ST0 and ST1 used to address the x87 stack when we can't perform operations in SSE. The reason the FP name exists is that the original x87 register allocation was to treat the x87 stack as a flat register file and perform trickery with stack exchange operations (fxch) to make it appear so.
Hide
Permalink
Ian Rogers added a comment -

Since the introduction of type registers the names of registers in opt compiler debug output is now sane. We aren't, however, dumping the XMM registers when we die because of a hardware trap. This is little more than tweaking the debug output so we should implement it for 2.9.3.

Show
Ian Rogers added a comment - Since the introduction of type registers the names of registers in opt compiler debug output is now sane. We aren't, however, dumping the XMM registers when we die because of a hardware trap. This is little more than tweaking the debug output so we should implement it for 2.9.3.
Hide
Permalink
David Grove added a comment -

I took a look, and this is annoyingly non-trivial.

The problem is that the header files (sys/ucontext.h vs asm/ucontext.h) are out of synch. We're using sys/ucontext.h and it doesn't have a way of naming the xmm registers.

Deferring this to later release. The actual coding is trivial if we had a portable way to name the right piece of the fpstate struct.

Show
David Grove added a comment - I took a look, and this is annoyingly non-trivial. The problem is that the header files (sys/ucontext.h vs asm/ucontext.h) are out of synch. We're using sys/ucontext.h and it doesn't have a way of naming the xmm registers. Deferring this to later release. The actual coding is trivial if we had a portable way to name the right piece of the fpstate struct.

People

  • Assignee:
    Unassigned
    Reporter:
    Ian Rogers
Vote (0)
Watch (0)

Dates

  • Created:
    Updated: