ok, it’s sorted now. turns out I somehow missed the -g2d at the Linking stage.
I’m starting to pick up on things a bit clearer now - I do think the -g2d helped, and I
now see that when an exception is thrown it upsets the debugger a bit - though it does
catch up again at the next break point.
The lack of ‘local variable’ watch is a little disconcerting - not sure what’s happened
there!
Lance Roberts wrote:
I now seem to have lost the ability to ‘Inspect’ or watch any of the variables. I’m
sure that used to work prior to using -g2d, but not sure if that is what changed it.
Any ideas about that?
Randy Martin wrote:
int 0xf2 is a kernel call. what is the value of al before the int 0xf2.
that will be the kernel call number, referenced from /usr/include/sys/kernel.h
Lance Roberts <> lance@econz.co.nz> > wrote:
I tried it with a large C only app, and it did the same thing on an Int 0F2 call (
i just held down F8 till it did it).
I repeated it with the one I’m having trouble with, and it also bombed on an int
0F2.
I guess that is inside something I tried to step over in the past? The debugger
loses its grip on the app at that exact point - the app runs normally after that,
but when I close the debug window the app dies along with it.
I can use wd to attach to a running app, step through until it hits the int 0F2,
close the window, then attach to it again, and continue, but I lose quite a few
steps in the process (takes a couple of seconds, and the task runs freely).
I don’t expect to be able to trace within interrupts which is what I assume it is
attempting.
I’m not sure if this is the same problem I was getting earlier, but the symptoms
are identical.
cheers
Lance
Randy Martin wrote:
can you please confirm that a simple c and c++ app work in this same
environment? so that a simple test case does not fail but that a larger
build environment does not work?
wd for 10.6 is dated jun22,97 ..
Lance Roberts <> lance@econz.co.nz> > wrote:
Ok, I’ve changed to -g2d for all my C++ modules (was -g).
Not all the source code is there (I should have probably mentioned that
earlier), so sometimes I just get a line number and the words ‘unable to open
source file’. All of the C++ code is there, but the main() is C - and the
code for it is not there, most of the C code is not there.
The crash still occurs, and basically the pterm I’m running the debugger in
just stalls - no keys or mouse will work, but I can slay the debugger or
close the pterm. The debugger releases its hold on the application at time
of stall, so that usually runs to completion anyway, and the debugger is
still stalled.
I’ve tried to get a ‘ps’ list to see what state the ‘wd’ task is in, but then
my phindows session, and in fact the entire remote qnx computer, freezes -
and so I have to reboot it (no screen or keyboard at the moment, but all
network (qnx + tcpip) stops).
Randy Martin wrote:
what debug format are you using?
for c++ i’d recommend -g2d and be sure to specify it on both the
compile and link phase.
how does it crash? with a segv?
Lance Roberts <> lance@econz.co.nz> > wrote:
Hi,
I’m having troubles with the Watcom 10.6 Debugger running on Qnx4.25
(e.g. Proc is v 4.25J Sep 09 1999).
Basically, the debugger crashes when I try and step from code in one
module to another. My ‘main()’ is within a C library that is linked to
a
C++ implementation module.
When the debugger crashes the program I was running just continues to
completion. I can set break points within the code, but only in some
modules, other modules it will bomb and the program just runs normally.
Is this a common thing that you can advise me something quick on, or do
you need more information?
cheers
Lance
=====================================================================
Lance Roberts
Analyst Programmer
email: > lance@econz.co.nz > web: > http://www.econz.co.nz
Ph: +64 9 361 1947 Fax: +64 9 378 9010
ECONZ (1971) Ltd. mail: PO Box 68-261, Newton, Auckland, New Zealand.
–
Randy Martin > randy@qnx.com
Manager of FAE Group, North America
QNX Software Systems > www.qnx.com
175 Terence Matthews Crescent, Kanata, Ontario, Canada K2M 1W8
Tel: 613-591-0931 Fax: 613-591-3579
–
Lance Roberts
Analyst Programmer
email: > lance@econz.co.nz > web: > http://www.econz.co.nz
Ph: +64 9 361 1947 Fax: +64 9 378 9010
ECONZ (1971) Ltd. mail: PO Box 68-261, Newton, Auckland, New Zealand.
–
Randy Martin > randy@qnx.com
Manager of FAE Group, North America
QNX Software Systems > www.qnx.com
175 Terence Matthews Crescent, Kanata, Ontario, Canada K2M 1W8
Tel: 613-591-0931 Fax: 613-591-3579
–
Lance Roberts
Analyst Programmer
email: > lance@econz.co.nz > web: > http://www.econz.co.nz
Ph: +64 9 361 1947 Fax: +64 9 378 9010
ECONZ (1971) Ltd. mail: PO Box 68-261, Newton, Auckland, New Zealand.
–
Randy Martin > randy@qnx.com
Manager of FAE Group, North America
QNX Software Systems > www.qnx.com
175 Terence Matthews Crescent, Kanata, Ontario, Canada K2M 1W8
Tel: 613-591-0931 Fax: 613-591-3579
–
Lance Roberts
Analyst Programmer
email: > lance@econz.co.nz > web: > http://www.econz.co.nz
Ph: +64 9 361 1947 Fax: +64 9 378 9010
ECONZ (1971) Ltd. mail: PO Box 68-261, Newton, Auckland, New Zealand.
–
Lance Roberts
Analyst Programmer
email: > lance@econz.co.nz > web: > http://www.econz.co.nz
Ph: +64 9 361 1947 Fax: +64 9 378 9010
ECONZ (1971) Ltd. mail: PO Box 68-261, Newton, Auckland, New Zealand.