-
Notifications
You must be signed in to change notification settings - Fork 89
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Instruction registers display is buggy/unreliable #32
Comments
FYI to those interested: here's our current Lines 306 to 380 in 97ef4d5
Is that crazy or what?! |
And the following trace display (created with
As you can clearly see, the If our opcode table contained more information about each instruction (like which registers it used, which operand(s) referenced storage, etc), our instruction tracing logic could use it to more accurately know what information it should be tracing. As it is today, we're wasting valuable host CPU cycles and log file disk space formatting and displaying unnecessary information, which slows down instruction tracing significantly. |
Note: this issue is closely related to issue #33: "Trace-to-file feature".
When instruction tracing/stepping is enabled (
t+
ands+
commands), Control, Floating Point and Access registers are not being displayed for some instructions which actually modify/use them. (See e.g.display_inst_regs
function inhscmisc.c
)Edit: The problem also occurs when an instruction is displayed as a result of an interruption too, such as when e.g. an Operation Exception or Translation Specification Exception occurs. That is to say, the problem is not limited to just the
t+
ands+
tracing/stepping commands. It is a general overall problem/issue with (design flaw in) thedisplay_inst_regs
function itself.Having the Control Registers also displayed whenever a program interrupt occurs for example, can be quite valuable information to have, as it can tell you in which address space the problem occurred for example.
The problem stems from the fact that the
display_inst_regs
function is deciding whether or not to also display the "other" registers (CR, AR, FPR) based on tests for specific instruction opcodes, which overly complicates the logic and makes it it less reliable and harder to maintain (e.g. it's easy to overlook updating this function when new instructions are added to the architecture for example).We need a more reliable, less error prone way to determine whether CR, AR, FPR should be traced or not for a given instruction. I'm thinking maybe an update to our existing OPCODE table might do the trick.
I propose adding
(*)
a new regsmask parameter to our existingGENx370x390x900
and related macros, that defines which registers the given instruction uses or modifies. Then thedisplay_inst_regs
function could then do a simple(?) table lookup to retrieve the mask, thereby reliably determining which registers should be displayed/traced.(*)
And adjusting all "opcode table" related code that might be impacted by such a change too of course. That is to say, I haven't researched yet the ramifications (impact) that adding a new field to our opcode table might cause.The text was updated successfully, but these errors were encountered: