Mail Archives: djgpp/2002/01/10/11:51:22
> Date: Thu, 10 Jan 2002 08:24:41 -0800 (PST)
> From: ROLAND <roland_asmann AT yahoo DOT com>
> >
> > and then type "disassmble 0x0f00115e", and see
> > whether GDB finds that
> > address in the program?
>
> I did that, and GDB said something like:
> No function at specified address
This means what I suspected: that address is not inside your program,
it's somewhere else.
> BTW, Do I need to put the PMCOM source in this dir as
> well? I just put in the .a file, but maybe it needs
> the sources as well...
No, the disassembly command doesn't need the sources.
> I tried something different now, I first opened the
> program in GDB and typed run, and then the program
> crashed.
> Now I set a breakpoint, and run again, and then used
> step from the breakpoint on. At that point everything
> seemed to go allright. After having used step for a
> number of times (I was in a while-loop) I decided to
> let the program continue, so it maybe ran into the bug
> somewhere. The strangest thing then was, that the
> program didn't crash!
Running a program under a debugger changes many things, in particular
how hardware interrupts are processed. So it's quite possible that
such bugs will behave differently under a debugger.
I think your best bet would be to read the sources of PMCOM and look
for code that uses DS, or accesses global variables without the CS:
override. Such code is prone to break when the foreground code uses
signals (like you do with SIGALRM).
- Raw text -