[Info-vax] Debugging shareable images on Integrity

[Neil Lowden]

On Apr 25, 9:55 pm, Neil Lowden <Neil.Low... at gmail.com> wrote:
> 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

Here you go, it was close to two years ago but....


Neil Lowden wrote:
> I came across odd behaviour with the debugger today under OpenVMS/I64
> V8.3.

This turns out to have been a bug in DEBUG. DEBUG was not flushing
the
i-cache on Integrity systems. This bug only appeared under the
following
circumstances:
1. Stepping over routine calls in an image installed /SHARE; and
2. Running on a Itanium Montecito processor
The failure symptom: STEP (by line, over a routine call) in the image
installed /SHARE causes an unhandled exception, %SYSTEM-F-BREAK_ARCH.
I've also heard of %SYSTEM-F-BREAK_SYS.
Cure: Fixed DEBUG so it flushes the i-cache. If you experience this
problem, contact HP support and reference WFM case 1216258317-121.
-Jeff