home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.sys.amiga.programmer
- Path: sparky!uunet!zaphod.mps.ohio-state.edu!darwin.sura.net!Sirius.dfn.de!chx400!bernina!wild
- From: wild@nessie.cs.id.ethz.ch (Markus Wild)
- Subject: Re: GCC - How to debug a program using ixemlib?
- Message-ID: <1992Aug18.130108.2023@bernina.ethz.ch>
- Sender: news@bernina.ethz.ch (USENET News System)
- Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH
- References: <PPESSI.92Aug18050721@vipunen.hut.fi>
- Date: Tue, 18 Aug 1992 13:01:08 GMT
- Lines: 30
-
- In article <PPESSI.92Aug18050721@vipunen.hut.fi> ppessi@vipunen.hut.fi (Pekka Pessi) writes:
- > using ixemlib. Is there some way to tell ixemlib that those
- > nasty ILLEGALs are really breakpoints made by my debugger?
-
- Hmm.. nah, the only way to have is to attach to an already running process.
- As soon as gdb can use a hunk libbfd.a, i'll go for ptrace(), which will
- enable a special SIGTRAP mode.
-
- > Also, what can I assume in atexit'ed function? Is stdio still
- > working? Or unix compatible system calls? (I want to restore
-
- stdio is closed as pretty much the last thing to happen in the atexit
- chain. system calls and lower level things in general should not present
- any problems. In C++, classes are destructed thru atexit, so you should
- call any non-static class members there.
-
- > stdin to cooked mode and disable all RAW event reporting.) If
- > I call restoring function before exit(), it works fine. If it
- > is atexit()'ed, result is a meditation moment.
-
- Strange...
-
- -Markus
-
-
-
- --
- Markus M. Wild - wild@nessie.cs.id.ethz.ch | wild@amiga.physik.unizh.ch
- Vital papers will demonstrate their vitality by spontaneously moving
- from where you left them to where you can't find them.
-