Re: [hatari-devel] fopen traces

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

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


> > However, grepping needs to be done for trace output,
> > and grepping works only on stdout, so it's actually
> > 
> > trace output that needs to be redirected:
> > 	--trace-file stdout | grep -v "Fwrite([12],"
> > 
> > This seems to prevent messed conout output.  Then
> > there's the verbose output of other commands (hundreds
> > of other GEMDOS calls per second), but that could be
> > easily be handled with extra greps.
> 
> 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! :-)

Then the output I was after would be:
	hatari --conout 2 --trace gemdos 2> >(fgrep -e Fopen -e Fclose -e Pexec 
-e Pterm)

Btw. This is pretty similar to what I use most often
on Linux for tracing problems with programs:
	strace -f -e open,close,execve <program>
:-)


> So, this seems similar to the result you get with
> an additional TRACE flag.

Yes, except for the debugger issue.

Even without that issue, this (with xconout redirection):
	hatari --trace os_base

Is nice non-technical shortcut for above, and it would work
also in situations where there's no Bash (e.g. Windows).
"os_base" is generic enough name that what it traces can
later be changes, if needed.


> > *However*, next thing that makes it unusable is that piping
> > Hatari output makes it impossible to use debugger as
> > you don't see what you're typing until you press Enter.
> 
> Using above command, I see the prompt if I enter the debugger, but not
> the result of 'm' or 'd'. Also 'h' only prints a very incomplete help
> list. So it seems some "prints" need to be fixed in debugger or
> disassembler to use stdout in all cases, I don't think stderr should be
> used.

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.


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


	- Eero