Re: [hatari-devel] fopen traces

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 26/05/2015 21:41, Eero Tamminen a écrit :
> Hi,
>
> On tiistai 26 toukokuu 2015, Nicolas Pomarède wrote:
> > Le 25/05/2015 22:39, Eero Tamminen a écrit :
> > > If I change conout to go to stdout, it seems to work OK.
>
> Do you think it would be OK to do this change to Hatari?
>
> It's an "API" change...

Hi

yes I can it's ok to change this

> > you can grep on stderr only using process substitution (in bash)
> >
> > eg :
> > hatari --trace fdc 2> >(grep seek)
>
> Nice, I didn't know about this! :-)

Yes, I admit this is not the common way to redirect output :)

> Debugger can call code all over Hatari, for example through
> "info" and "setopt" (command line option) commands.  Fixing
> all that would be massive change.
>
> Hatari has few thousand prints, of which 1/3 goes to stderr, see:
> $ find src/ -name '*.c' | xargs grep -e printf -e fput |\
> 	grep -v -e gencpu.c -e build68k.c -e Dprintf -e ':\w*//'
>
> Looking at the output there are some clear inconsistencies
> which should be fixed, but error messages seems to go fairly
> consistently to stderr.  For debugger to be usable, error
> messages for its commands should naturally also be visible.
>
> I don't think changing all Hatari error messages which could
> be triggered by debugger, to go to stdout, is worth this.

Still, I think I will change those in cpu/* uae-cpu/* to use stdout when 
it's supposed to be called from the debugger.

In src/*, I think some could be easily fixed in the "xxx_Info()" 
functions (for example Video_Info). It would be better to add a "FILE *" 
parameter and let the uppper level calling function pass the correct 
value (stdout, stderr, or even a real file in case we want to use 
--trace-file)


> -> I'll change "fopen" to "os_base" trace which tracks
>     fopen/fclose/pexec/pterm and I'll enable xconout
>     redirection for both os_base & os_all.
>
> Tracking Pexec will also tell Hatari users why "pc=text"
> breakpoints trigger multiple times at TOS boot, and not
> just when the program user is trying to debug starts.  :-)

OK

Nicolas