BEAR tracing support?

[Fish-Git]

Hi guys!

With the introduction of the new BEAR-Enhancement Facility (#193), I was thinking it might be a nice debugging feature if Hercules supported the ability to either: a) trace all occurrences of the BEAR being updated, or b) maintain a short history of BEAR values, or possibly both.

As for the history, I'm thinking of a new command where the user could ask Hercules to automatically maintain a history of the last 'nn' BEAR values (where 'nn' would be capped at some reasonable value, say, 256 or 1024, etc).

For tracing, we would simply automatically trace just that one instruction (whatever instruction it happened to be) that caused the BEAR to change. Such a trace would certainly allow the user to more easily see just the guest's flow of execution if that's all they're interested in, without the tracing of all of the other instructions getting in the way (i.e. such a trace would certainly be much less "verbose").

What do you think? Is it worth doing? And if so, which one? Maintaining a history might be something that could be implemented fairly quickly and easily (I hope!), whereas tracing each BEAR update might take a bit more effort (but should still be fairly simple to implement I should think/hope).

What do you think?

Thanks!

[mcisho]

I believe it would be effort for very, very limited benefit. The main problem with a simple branch trace is that the vast, vast majority of events are in code in which one generally has no interest, i.e. operating system facilities or library functions that have been called by the code in which one does have interest. IMHO, upgrading the Hercules instruction tracing commands (t/t+/t-) to only trace taken branches would be a better use of the effort.

For years I have worked with code running in virtual machines under the various VM's, and use the CP TRACE (once upon a time known as the CP PER) command a lot. However, I never use the TRACE BRANCH command without filters (e.g. address range, ASN, etc), or the INTO operand, because the number of events recorded becomes too large to be useful.

Ian

[Fish-Git]

Hmmm... I think I see what you're getting at. What you want is a new instruction tracing feature that provides the ability to only trace branches that occur within a given address range , and, optionally, whose target is within a given address range (where the target range can optionally be specified as either the "same" range or a completely different range). Yes? Am I understanding you correctly?

For example: given the pseudo-program segment:

    1            LTR   R5,R5
    2            BZ    SKIP
    3            L     R15,ASYS1
    4            BASR  R14,R15      Call system function
    5   SKIP     CLR   R6,R7
    6            BH    ERROR
    7            ...
    8            ...
    9   ERROR    BAS   14,MYMSGSUB
    10           ...
    11           ...
    12  MYMSGSUB ST    R14,SAVE14
    13           ...
    14           L     R15,IOFUNC
    15           BASR  R14,R15      Call system function
    16           ...
    17           L     R14,SAVE14
    18           BR    R14

You want the ability to specify e.g. t+ branches 1-11 into same, which would only trace the branches at 2 and 6, but not the branches at 4 (target outside of range) or 9 (target outside of range) or 15 (branch instruction itself outside of range) or 18 (branch instruction itself outside of range). Yes?

Presuming I'm understanding you correctly, then yes, I agree! That would definitely be a very handy feature to have and would certainly make debugging one's code much easier! Of course implementing it might be somewhat of a PITA, but it would definitely be worth it I think! Great suggestion, Ian! Thanks!

Anyone else?

[mcisho]

Yes, you have understood me correctly.

[Fish-Git]

Ian (@mcisho),

I have created a new separate GitHub Issue to formally request your desired tracing enhancement, and am closing this issue as "Won't Fix" since it's clear my originally proposed BEAR tracing idea does not provide enough value.

I really appreciate your thoughtful feedback.