Re: [hatari-devel] fopen traces

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 31/03/2015 00:04, Eero Tamminen a écrit :

> > For example : --trace gemdos --trace_os fopen,fclose,fread
>
> While that's otherwise fine idea, I don't see use for such
> an option.  From ~7 years of tracing things with Hatari,
> Fopen() has been the only OS call where there's clear,
> frequent use-case for tracing it on its own.
>
> (For rest, you typically need all the calls, just in case.)

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.

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)

> > Then, as OS calls are not supposed to be called that often, one can use
> > a simple search list when logging instead of a bitmask for the list of
> > OS functions (which could exceed 64 and not go into a Uint64).
> >
> > if ( LOG_TRACE_LEVEL ( TRACE_OS_GEMDOS ) && ( LOG_TRACE_OS ( "fopen" ) )
> > {
> >    LOG_TRACE_PRINT( "fopen ...." );
> > }
>
> 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.

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


What's the opinion of other people ? Thomas maybe ?


Nicolas