weier@twolf4.CE.YALE.EDU (Richard Weier) (10/18/90)
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! Another problem with this version of dbx is that it does not recognize conditional break points when a program is rerun. The break points show up with the status command, but they are ignored. Deleting break command and retyping the same thing over causes it to work.
mao@eden.Berkeley.EDU (Mike Olson) (10/19/90)
In <26832@cs.yale.edu>, weier@twolf4.CE.YALE.EDU (Richard Weier) 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! as TFM explains, "call" is "func" using dec's dbx. apparently compatibility wasn't the first thing on their minds. there are other minor annoyances; having the last action repeated when you hit carriage return really sucks when you have a bouncy keyboard, and making ^D behave non-deterministically was a bad idea. the list goes on... curse me for a heathen, but i *really* wish there were an adb for the pmax chip, and we could stop compiling such obese programs. still, even dec's dbx beats printf()'s. mike olson postgres research group uc berkeley mao@postgres.berkeley.edu
hudgens@sun13.scri.fsu.edu (Jim Hudgens) (10/19/90)
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!
We recently complained about this through the proper channels.
The person I spoke to mentioned that he would file a QAR (???) or something
like that. This cripples dbx for one person here who needs it
for a FORTRAN application which uses fairly complicated data structures
built out of arrays, and needs the ability to call a print routine
which pretty prints the data-structure.
Another problem
with this version of dbx is that it does not recognize conditional
break points when a program is rerun. The break points show up with
the status command, but they are ignored. Deleting break command and
retyping the same thing over causes it to work.
I noticed several problems with the debugger in this area as well.
If both a tracepoint and a breakpoint are set, only one of them
will have any effect (maybe not true in general, but definitely
true for the code I was debugging). This hasn't been reported (yet).
Also, how does one catch an overflow/underflow/divide-by-zero error
under dbx? Is there a standard way to have a signal delivered
when a floating point error occurs?
--
Disclaimer: I didn't do it.
Jim Hudgens Supercomputer Computations Research Institute
hudgens@sun13.scri.fsu.edugrr@cbmvax.commodore.com (George Robbins) (10/19/90)
In article <1179@sun13.scri.fsu.edu> hudgens@sun13.scri.fsu.edu (Jim Hudgens) writes: > 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! > > We recently complained about this through the proper channels. > The person I spoke to mentioned that he would file a QAR (???) or something > like that. If I recall, QAR channel is appropriate for Field Test sites, normal sites file an SPR (sofware performance report) instead. In either case complaining is likely to be ineffective, you must get some paper filed. If you have access to the normal support center channels, you can get the support center people to do this for you, but you may have to insist, it doesn't happen by default. You should also make your sales person aware of serious problems that affect the usability/value of the product, it can't hurt. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing: domain: grr@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)
weier@twolf4.CE.YALE.EDU (Richard Weier) (10/30/90)
In article <15270@cbmvax.commodore.com>, grr@cbmvax.commodore.com (George Robbins) writes: |> > 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! |> |> If I recall, QAR channel is appropriate for Field Test sites, normal sites |> file an SPR (sofware performance report) instead. In either case complaining |> is likely to be ineffective, you must get some paper filed. If you have |> access to the normal support center channels, you can get the support center |> people to do this for you, but you may have to insist, it doesn't happen |> by default. |> |> You should also make your sales person aware of serious problems that affect |> the usability/value of the product, it can't hurt. |> 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.
hudgens@SCRI.FSU.EDU (Jim Hudgens) (10/30/90)
|> > 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
brian@cimage.com (Brian Kelley) (11/03/90)
In article <26959@cs.yale.edu> weier@twolf.ce.yale.edu writes: > >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. The changes to dbx in 4.0 have broken the xdbx front-end to dbx. Has anyone patched xdbx to work with the dbx supplied in 4.0? --- brian@cimage.com