Re: [hatari-devel] fopen traces

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

On tiistai 31 maaliskuu 2015, Nicolas Pomarède wrote:
> I guess usage varies, because I never had to do this. When debugging, I
> usually throw everything into a file with as much details as possible to
> get a 1st overview of the problem, then I grep this file for some
> specific keyword.
> 
> "hatari --trace gemdos 2>trace_file"  then "grep xxxx trace_file"
> doesn't look that much limited to me.

I do both, viewing more limited trace at run-time, and redirecting
os_all etc data into file & reading it later from there.  One does't
replace the other, they're complementary.

Viewing (reasonable amount of) trace at run-time is necessary when one
needs to correlate it to what the application does (what it outputs to
screen, what notes it's playing on MIDI etc).

I normally start with that, and if it doesn't tell enough, I use
its information to find out correct place from a saved full trace.

Fopen() output can also be used as progress indicator with some
programs which data loading takes minutes. :-)


> > For example, booting to desktop with "--trace gemdos" produces approx
> ~200 lines, that's hardly a big output (and of those 200 line, ~150 are
> fsnext)

E.g. some programs linking MiNTlib can do a lot of calls.  You
can in couple of seconds get the interesting lines scrolled out
of two thousand line terminal back buffer, especially if you're
using fast forward to skip non-interesting parts.

(Last example of this is OpenTTD, it uses SDL & MiNTlib and needs
tens/hundreds MBs of TT-RAM. It doesn't yet work with Hatari, no
idea yet whether issue is in program itself or in Hatari emulation.)


> > There's still ~dozen trace flags free.  What kind of things
> > you've though they would be occupied by?  Hatari already emulates
> > about all HW (some things are still missing tracing, e.g. MMU,
> > but not that many).
> 
> No idea at the moment, but I'd rather keep some free space in the list
> than removing some options later to keep everything in 64 bits.

It doesn't necessarily need to be removed, some trace options can
later be changed to use another mechanism without changing the option.

There can e.g. be two separate trace flag variables like you
proposed.  How things are split between them could be decided
when we actually run out of current flags, it doesn't necessarily
make sense to decide it now.


> IMHO trace level is about some broad categories of hardware components
> (cpu, blitter, video, sound, fdc, ...) and some families of OS
> calls/TRAPs.

IMHO couple of most frequent usages could have their own flags.

Haven't you ever wanted something more focused because you
use it constantly and most of rest is often just noise?


	- Eero

PS. Thomas change suggestions make sense, I'll look into them later.