Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!ginosko!uunet!mcsun!ukc!edcastle!hwcs!zen!frank
From: frank@zen.co.uk (Frank Wales)
Newsgroups: comp.sys.hp
Subject: Re: HP-UX s800 xdb question
Message-ID: <1734@zen.co.uk>
Date: 18 Oct 89 14:02:49 GMT
References: <1728@zen.co.uk> <7370014@hpfcso.HP.COM>
Reply-To: frank@zen.co.uk (Frank Wales)
Organization: Zengrange Limited, Leeds, England
Lines: 82

In article <7370014@hpfcso.HP.COM> jmn@hpfcso.HP.COM (John Newman) writes:
>In article <1728@zen.co.uk> I wrote:
>> xdb(1) takes a *long* time single-stepping the return of a large
>> structure.  Here is the example program I sent to our Customer Response
>> Centre (instructions start in main's comment block):
>> [code fragments deleted]
>>
>> My question is simply: why does this happen?
>
>Here we have an example of what it means to debug on a RISC machine :-)
>
>[detailed explanation deleted]
>When in single-step mode, there is a considerable amount of
>context-switching overhead, and the debugger actually single-steps at the
>*instruction* level.  So for this one C statement, the debugger is actually
>single-stepping the process thru approx.  770 instructions, one at a time,
>with control passing back and forth between the debugger and the child for
>each instruction executed.  This takes enough time as to be noticible to
>the user.

Yep. :-)  Thanks for the info, John, it's just what I wanted to know
(and roughly what I'd guessed).  [BTW, why does removing the enum from
the struct definition slow things down further?  Just curious. :-)]

>> And is there a tweak I can apply *now* to get rid of it? ;-)
>
>If you must single-stepping thru a return statment that returns a large
>structure, no there isn't.  As a workaround, there's a couple of things you
>could do:
>
>	1. Upon reaching the return statement, use the "bu" command to set
>	   an uplevel breakpoint (which wil be at the 1st instruction
>	   following the return), and continue ("c") to it.  This takes the
>	   debugger out of single-step mode, and all 770 instructions
>	   execute at full speed, all at once.

This (or "bx", depending on the mood I'm in) is what I do use, when I
remember to not just keep tapping [return].

>	2. Return a pointer to the structure, rather than the entire
>	   structure.  This means the return statement effectively compiles
>	   into 2 (two) instructions, which are stepped thru quickly and
>	   easily.

Not practical, given the current software design (mallocing result
values complicates things hideously, and having them statically
allocated defeats re-entrancy, which is one of the requirements for many
of the routines which return these objects).

>BTW, Frank, we have seen the SR you filed concerning this, to be appearing
>in a Software Status Bulletin (SSB) near you soon.  Unfortunately, because
>of the process overhead inherent in using single-step mode, and because
>such a large amount of data must be moved with this sort of return
>statement, there really isn't a "fix" possible (not on a RISC architecture,
>anyway).

[sticks finger in air and puts on his best air of confident ignorance]
But wait!  Since this can be made to work quickly by the general
strategy of "set a temp. breakpoint on the next instruction and
continue to it," why can't xdb do this for me?  Debugging at the source
level, I don't care about possible side-effects or assertion hits
*within* the execution of a single source statement.  If I did, I could
toggle into assembly mode and force instruction-by-instruction
debugging.  So, is this feasible?  I.e., does the set/continue approach
to source-level stepping work equivalently to the current approach for
all (common) cases?  If so, could I have it, please?  ;-)

>> [By the way, why are the "Procedures:" and "Files:" counts presented on
>> xdb entry both one too large under 3.1?]
>
>When debuggable programs are linked, there is an extra object file that is
>added:  on the s800, it's named /usr/lib/xdbend.o.
>Inclusion of this file (which is itself debuggable) increases both the
>"Procedures:"  and "Files:"  counts both by 1.
>
>I don't think this is clearly documented anywhere.  I believe it should be,
>and will endeavor to make it so.

Thank you, John.
--
Frank Wales, Systems Manager,        [frank@zen.co.uk<->mcvax!zen.co.uk!frank]
Zengrange Ltd., Greenfield Rd., Leeds, ENGLAND, LS9 8DB. (+44) 532 489048 x217