[Info-vax] Debugging shareable images on Integrity

[Neil Lowden]

On Apr 23, 2:43 pm, jcwoman1... at hotmail.com wrote:
> Hi,
>   I have a routine that's embedded in a shareable image that I need to
> step through in the debugger in order to locate a problem.  I've been
> able to do this with the same code on Alphas with no problem, but it
> appears that the debugger behavior has changed a little on Integrity,
> but I'm not sure how to compensate for it.  Here is what I mean:
>
>   My image is installed with the INSTALL/SHARE command. No priv's or
> other installer parameters.  The shareable modules and my application
> are written in Macro.  I compile and link it and my application that
> calls it with the debugger.  I can verify this because the image size
> is larger.  Also, it does display the sharable image source code in
> the debugger.  But, when I try to step through the module's source
> code, it just displays the same line of code over and over again.
>
>   More precisely here is what I'm doing:
>
> Install the shareable.  Run my application in the debugger, and
>
> SET IMAGE SHRLIB
> SET MODULE HISLIB
> SET BREAK HIS_SFHR
> GO
>
> Then when I send the application command and it hits the breakpoint,
> it does break at the .ENTRY and displays the source of the HIS_SFHR
> module.  Great!  From this point on, step does nothing but display
> the .ENTRY line over and over again.  If I set another breakpoint
> inside the module, say the next executable line and type GO, it does
> NOT stop at the breakpoint.
>
> I've been perusing the Debugger help menus with no ideas so far.  I've
> checked that my STEP is defined as:
>
> step type: nosource, nosilent, by line, over routine calls.
>
> Even when I change the step type to "source", I get the same
> behavior.  What am I missing?  (Also, what details have I forgotten to
> include here to help you guys help me?)

Hi

Sounds similar to a problem I experienced a year or so ago. This was
traced to a bug in the debugger on Montecito CPUs (there was no
problem on previous Madisons). The debugger was not flushing an
instruction cache on Montecito systems after setting a breakpoint in
main memory and therefore probably leaving the original instruction in
cache. In my case this was rapidly fixed by a custom patch from the
debugger team. Not sure if or when that patch was rolled into a public
patch but you should certainly check this with HP.

Regards

-Neil