From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!husc6!uwvax!tank!nic.MR.NET!shamash!rosevax!ems!srcsip!bozon!eisen
From: eisen@bozon.SRC.Honeywell.COM (Greg Eisenhauer)
Newsgroups: comp.lang.ada
Subject: Re: User requirements on generics
Message-ID: <13631@srcsip.UUCP>
Date: 17 Dec 88 22:58:56 GMT
References: <8812161453.AA02985@aries> <10479@umn-cs.CS.UMN.EDU>
Sender: news@src.honeywell.COM
In-reply-to: stachour@umn-cs.CS.UMN.EDU's message of 17 Dec 88 17:06:01 GMT
List-Id: <comp.lang.ada>

In article <10479@umn-cs.CS.UMN.EDU> stachour@umn-cs.CS.UMN.EDU (Paul Stachour) writes:

   Path: srcsip!ems!amdahl!ames!xanth!nic.MR.NET!umn-cs!stachour
   From: stachour@umn-cs.CS.UMN.EDU (Paul Stachour)
   Newsgroups: comp.lang.ada
   Date: 17 Dec 88 17:06:01 GMT
   References: <8812161453.AA02985@aries>
   Reply-To: stachour@umn-cs.cs.umn.edu (Paul Stachour)
   Organization: CSci Dept., University of Minnesota, Mpls.
   Lines: 14

   In article <8812161453.AA02985@aries> emery@ARIES.MITRE.ORG (David Emery) writes:
   >  ... 
   >Note that code sharing can affect the debugger's ability to do this.
   >If code sharing for STACK_PACKAGE is true, then the debugger may not be
   >able to support setting a breakpoint inside a specific instance.  

   Dave, I don't see why this must be true.   From the debuggers's viewpoint,
   one sets a breakpoint in the shared-code for the generic.  When the 
   breakpoint is hit, the debugger checks the context of the breakpoint
   with respect to who did the calling from what line, etc., and thus can
   determine from the symbol-table info which instance of the generic that
   it is actually in.  The breakpoint is "taken" if that is the instance
   in which the breakpoint was set, otherwise the breakpoint is "ignored".
     ...Paul

The "symbol-table information" that you propose to use would have to be much
more complex than the information that is generated and used in many systems.
A simple virtual-address to source-line mapping, as is produced by the Verdix
Ada system is not sufficient.  Consider that you may have calls to several
generic instantiations in a single source line.  It will be difficult for the
debugger to figure out which call is actually being performed.  It can perhaps 
be done, but if you think about a case like a lengthy expression where all of
the operators are generic instantiations with shared bodies, things get hairy
fast.

An easier approach might be to create a stub subprogram for each instantiation
that did nothing but call the shared code.  That way the debugger would have
something unique on the call stack for each instantiation.  Unfortunately, you
also have the expense of 2 procedure calls where you got by with one before.
Might be too high a price to pay just to be able to set breakpoints in
separate shared instantiations.  Another option would be to have the compiler
generate an extra parameter to generic routines that identified the
instantiation.  Verdix does this for other reasons, so it should be feasable
for the debugger to use it to disambiguate the call.



Greg Eisenhauer, Honeywell SRC		     Socrates, Pythagoras,
Phone: (612) 782-7318			     Yin and bloody Yang,
MAIL:  3660 Technology Drive, Mpls, MN       Hatha Yoga, Ommm,
ARPA:  eisen@src.honeywell.com		     Bennet, Gurdjieff, Jesus
UUCP:  {umn-cs,ems,bthpyd}!srcsip!eisen		-- Peter Murphy