|Re: [hatari-devel] A question about the debugger|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On tiistai 15 syyskuu 2015, Roger Burrows wrote:
> On 14 Sep 2015 at 22:14, Roger Burrows wrote:
> > On 15 Sep 2015 at 0:08, Eero Tamminen wrote:
> > > Then you need also to tell Hatari to invoke debugger on
> > > the specified exceptions. Easiest way to do that is to
> > >
> > > add "autostart" option:
> > > hatari --debug-except bus,autostart ./test.prg
> > >
> > > This will enable exception debugging after program
> > > is autostarted, to avoid TOS bootup exceptions invoking
> > > the debugger.
> > The program doesn't get autostarted, perhaps because my C drive is an
> > emulated ACSI drive, not the GEMDOS drive. But I'll see if the
> > debugger still gets invoked on the crash.
> It apparently doesn't.
Yes, autostarting relies on hooking TOS *.INF file
loading, which can be done only with GEMDOS drive
(And the above --debug-except autostart option hooks
into autostarting functionality.)
> > > (Alternatively you can use "setopt -D" command in debugger
> > > to toggle at run-time whether previously specified exceptions
> > > invoke the debugger or not.)
> > Will it work if I add "setopt -D" to the debugger initialisation file?
> > I guess
> > I'll try if all else fails.
> I tried this. The debugger is entered when the first bus exception
> happens during EmuTOS initialisation.
And every other matching exception TOS bootup does...
> After typing 'c' to continue, the
> logfile is closed and all trace output goes to the console.
I've fixed this along with symbol trace not going to trace file:
Should be part of next Windows snapshot.
> > > After scripting the debugging, you don't need to interact with
> > > debugger, so you can just start Hatari directly from DOS prompt
> > > and redirect all Hatari output to a file.
> > Ah, now we're back to my original problem: attempting to redirect
> > debugging output to a file did not seem to work for me in Windows.
> > But I don't care as long as I can get a workaround ...
> Unfortunately none of the above worked, and trying to redirect stderr via
> 2>debug.log doesn't want to work in the Windows implementation.
I've used stderr and stdout redirecting from Windows DOS
prompt (at work) and it has worked fine for the programs
What exactly means "doesn't want to work"?
- That only part goes to stderr and part to stdout
- That if you redirect both, nothing is in either of