sjw_nc@caen.engin.umich.edu (Scott J Wilderman) (05/28/90)
I have had nothing but trouble with dde and entry points, and
I am wondering if others have had the same problems. I can not
understand the following things:
1. I can not set a break point on an entry point name.
2. I can not 'step' from a main program to an entry point - it's
treated as 'go'.
3. If I type 'break sub_name' or 'env sub_name\', where
'sub_name' is the routine containing entry points, the active
environment gets set to the first statement after the last entry
point.
====================
In general, I'm not sure I think OS 10's 'dde' is an improvement
over 9.7's 'debug'. There are a few 'neat' features, but
in addition to introducing some bugs (on 10.1) that make things
hell (all floating points less than 10**-5 print as 0. - what
a travesty), 'dde' removed some features of 'debug' that I used
and liked have disappeared. At least it's better than dbx.
====================
Scott Wildermanrehrauer@apollo.HP.COM (Steve Rehrauer) (05/31/90)
In article <1990May27.225011.8276@caen.engin.umich.edu> sjw_nc@caen.engin.umich.edu (Scott J Wilderman) writes: >I have had nothing but trouble with dde and entry points, and >I am wondering if others have had the same problems. I can not >understand the following things: > >1. I can not set a break point on an entry point name. Have you APR'd this problem? What exactly do you mean by "can not set a break point on an entry point" -- does DDE complain in some fashion, or do you just never hit the breakpoint during execution of your code? I ask because problems of this nature are often *compiler* bugs, not DDE bugs. If the compilers feed incorrect debug information into the object file, it's usually poor ol' DDE who appears to be at fault. (In fact, I just found & fixed an apparently VERY old bug of this nature in the 68k code-generator. You could set a DDE entry breakpoint, but due to a compiler bug, DDE believed that the first user-visible executable instruction in the procedure in question was an instruction that actually was unreachable from any execution path!) To determine if this is really a compiler problem, you might try using the -dba compiler option (-W0,-dba for /bin/compilers); I assume you're using -dbs or -db now. -dba disables all but the most trivial of optimizations. If it does what you expect in DDE when compiled with -dba, then it's almost certainly a compiler problem. Caveat: I'm using a more recent OS, compilers and DDE than you are, so I may just be blowing smoke. >2. I can not 'step' from a main program to an entry point - it's >treated as 'go'. Ummm, not to insult your intelligence or anything, but I assume the entrypoint lives within the module, or if not, has also been compiled for debugging? Assuming you're not doing anything silly, then this also sounds like it may be a compiler problem. Again, please APR it so we can [a] determine if it's already been fixed, and in what release if so, or [b] fix it in a future release. >In general, I'm not sure I think OS 10's 'dde' is an improvement >over 9.7's 'debug'. There are a few 'neat' features, but >in addition to introducing some bugs (on 10.1) that make things >hell (all floating points less than 10**-5 print as 0. - what >a travesty), 'dde' removed some features of 'debug' that I used >and liked have disappeared. At least it's better than dbx. Hmmm, are you sure about the floating-point business? I suppose a DDE person should really answer that one for you, but I've never had a problem like that. (I HAVE had problems where values assigned to registers sometimes don't get properly tracked through a DDE session -- again, this may be a compiler problem. In which case I guess that means I should fix it... :-) -- >>"Aaiiyeeee! Death from above!"<< | (Steve) rehrauer@apollo.hp.com "Spontaneous human combustion - what luck!"| Apollo Computer (Hewlett-Packard)