Re: [hatari-devel] fopen traces

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On maanantai 25 toukokuu 2015, Nicolas Pomarède wrote:
> Le 25/05/2015 21:21, Eero Tamminen a écrit :
> > Have you used Hatari's console redirection option
> > with GEMDOS (or BIOS) tracing on graphical programs
> > that output their error messages to console?
> > 
> > As I stated earlier, tracing messes up conout output
> > and there's no way to fix that like you think [1].
> 
> I still think another possibility could have been that each
> gemdos/bios/xbios function writes its name in each LOG call. This way
> you can do "|grep -i -e fopen -e fclose -e ..."

All OS call traces should already have a prefix,
that's not a problem.


> LOG prints go to stderr, so it should be possible to separate them from
> conout's output that goes to stdout ?
>
> IMHO redirecting stderr to "| grep" would do the trick in many cases

Both traces & conout go to stderr.

If I change conout to go to stdout, it seems to work OK.

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.


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


This is the reason why I don't use redirection/piping,
except for test-runs which debugging I've already fully
automated with chained / scripted breakpoints, or when
I need to get full trace output for post-mortem analysis.


	- Eero