Path: utzoo!attcan!uunet!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!uflorida!gatech!prism!sun13!sun13.scri.fsu.edu!hudgens From: hudgens@SCRI.FSU.EDU (Jim Hudgens) Newsgroups: comp.unix.ultrix Subject: Re: ds5000/200 Ultrix4 dbx problems Message-ID: Date: 29 Oct 90 17:31:29 GMT References: <26832@cs.yale.edu> <1179@sun13.scri.fsu.edu> <15270@cbmvax.commodore.com> <26959@cs.yale.edu> Sender: hudgens@sun13.scri.fsu.edu Organization: SCRI, Florida State University Lines: 64 In-reply-to: weier@twolf4.CE.YALE.EDU's message of 29 Oct 90 16:48:30 GMT |> > In article <26832@cs.yale.edu> weier@twolf.ce.yale.edu writes: |> > |> > It appears that dbx for the DS5000 provides no way of calling a |> > function. Why has the extremely handy "call" command been removed? |> > This drastically cuts into our development efficiency! > Last week I gave DEC a call about this problem. This morning I got a > call from a DEC employee who said that they have recieved many > complaints about the missing dbx "call" function. The problem has been > fixed and the "call" function is going to be available with the next > release. Until then, we can all use the "print" command discoverd by > Lavagno. It doesn't work from fortran. ----- a=10. b=20. c=30. stop end subroutine foo(a,b,c) print*,"hello ",a,b,c return end ----- $ dbx2.1 a.out dbx version 2.10 Type 'help' for help. reading symbolic information ... [using pf.MAIN] MAIN: 1 a=10. (dbx2.1) stop at 4 [2] stop at "pf.f":4 (dbx2.1) run [2] stopped at [pf.MAIN:4 ,0x400230] stop (dbx2.1) print a 10.0 (dbx2.1) print foo(a,b,c) a not active (dbx2.1) where 0 foo(a = [bad address (0x272c658f)], b = [bad address (0x5c7c2)], c = [bad address (0x272c658f)]) ["pf.f":4, 0x400258] 1 _mcount(0x5c7c2, 0x272c658f, 0x5c7c2, 0x272c658f, 0x5c7c2) ["./crt0.s":145, 0x4001d8] (dbx2.1) run dbx2.1: fatal error: value_from_regs: got reg(31) without entry $ ------- Oh, well. An explanation for the above is beyond me. I've tried other approaches (common blocks, etc.) and get differing failures. We await the next release. -- Disclaimer: I didn't do it. Jim Hudgens Supercomputer Computations Research Institute hudgens@sun13.scri.fsu.edu