Re: [hatari-devel] fopen traces

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On sunnuntai 24 toukokuu 2015, Nicolas Pomarède wrote:
> Le 24/05/2015 18:30, Eero Tamminen a écrit :
> > On keskiviikko 13 toukokuu 2015, Eero Tamminen wrote:
> >> Besides Fopen/Fclose, I think also Pexec & Pterm* would
> >> be interesting, because you can see from Pterm whether
> >> program terminated abnormally.  However, I'm not sure
> >> what this kind of trace option should then be named...
> > 
> > Maybe gemdos_min, os_min (vs. os_all) or minimal?
> 
> or os_base?

I like that.  I was thinking that "os_base" and "os_all"
could also enable "--conout 2" unless user had already
requested tracking of some other xconout vector input.

Btw. While GEMDOS (or BIOS) catch console output from
applications (which may not be visible in Hatari window),
conout can catch also other console output like EmuTOS
panic messages.  One EmuTOS optimization was actually
reverted because it broke this.


> Note that IMHO and given the lack of response here,

That's because most people don't try to debug MiNTlib
linked programs ported from Linux (ScummVm, OpenTTD,
Doom...) under Hatari e.g. to see what problems
they have under plain TOS (so that they can be fixed).


> I still think this option is redundant and should be
> handled by the user using current os traces with some
> proper file redirections + filter/grep :)

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


	- Eero

[1] You would need to parse GEMDOS write commands,
and buffer output from those (in case they go to console),
until there's something else from GEMDOS that doesn't
go to console, and only then output what you buffered.

Additional complication is that conout output can
prefixes these lines with random characters (including
line editing ones like new line and carriage return).

(BIOS writes have same issue with conout output, but
BIOS call traces are so rarely interesting that it's
not really a problem.)

Alternative to buffering would be to filter out all
non-interesting GEMDOS calls, but there's a lot of
them (nearly hundred in total) and you still need
to take mixed conout output into account.