|Re: [hatari-devel] fopen traces|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
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
"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
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 ?