Re: [hatari-devel] fopen traces

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On tiistai 31 maaliskuu 2015, Nicolas Pomarède wrote:
> Eero, I see you added a trace level just for gemdos fopen, but I'm not
> sure we should allocate its own bit in the log mask just for 1 function
> call, as we're limited to 64 bits and we should try to have broad
> categories here, especially when it's rather easy to run hatari with
> "--trace gemdos" and send the output to "grep -i fopen"

That's not the same thing at all.  It will lose all the other useful
messages.  E.g. "--trace fopen --conout 2" is very useful for initial
debugging of why some programs don't work (iterative fixing of file
paths, names, access rights etc).


> Maybe a better, more general solution would be to have a list of OS
> calls to trace and provide them through an option similar to --trace
> syntax.
> 
> 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.)


> 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).


	- Eero