Logging breakpoints to trace file

[wietze]

Hi there guys,

Im getting my feet wet in Hatari tracing. I can use the regular trace options to write events to a log file, which is awesome. I wish to now further capture more information into the log file, by expanding its writes to the logfile with logging set breakpoints.

However, when I do `b pc=$addr :trace', the output is hit to console, and not to the trace logfile. The documentation is quite comprehensive, but so far I have not found a way to direct the logging of breakpoints towards the trace file.

Does anyone know if this is possible? And if it is, how to do this?

Would be much appreciated,
Kind regards
wietze spkr/smfx

[wietze]

I think I kind of sovled my situation. By using a configuration file that contains the trace and breakpoint configuration, I can start hatari, and direct the output from hatari towards a file; and it seems all logging is then accumulated into one file.

F.e.:

Code: Select all

./hatari --parse trace.ini >test.log 2>&1

With trace.ini:

Code: Select all

trace video_vbl
b pc=$712 :trace
b pc=$718 :trace

[wietze]

One more question, can hatari monitor memory writes? I would like to know when an interrupt vector changes.

[npomarede]

One more question, can hatari monitor memory writes? I would like to know when an interrupt vector changes.

Hi
yes it's possible. You can set a breakpoint that compares the content of memory :
If VBL points to $e01234 and you want to monitor its change :

Code: Select all

b ($70).l ! $e01234

If you want to monitor any change, you can even do

Code: Select all

b ($70).l ! ($70).l

At the moment, Hatari doesn't monitor memory writes / reads yet, but using the '!' you can still break on some writes for most cases.

Nicolas

[Eero Tamminen]

Im getting my feet wet in Hatari tracing. I can use the regular trace options to write events to a log file, which is awesome. I wish to now further capture more information into the log file, by expanding its writes to the logfile with logging set breakpoints.

However, when I do `b pc=$addr :trace', the output is hit to console, and not to the trace logfile. The documentation is quite comprehensive, but so far I have not found a way to direct the logging of breakpoints towards the trace file.

":trace" option just tells breakpoint not to invoke debugger, so that breakpoints can be used for tracing. I hadn't even considered that the breakpoint output itself should go to the trace file, because I've mainly used them either to check whether something happens at all (i.e. only little output), or to run debugger scripts with ":file" option, in which case breakpoints can output basically anything, and parts of that output would already go elsewhere [1].

I.e. just redirecting whole Hatari output is probably the best option for breakpoint output. Note that if you want to see the output live, while it's being saved, you can use "tee" unix command.

(I'm not sure whether output redirection can be easily done on Windows though, so it could be a problem for users on Windows?)

[1] Hatari actually has currently 5 different outputs:

• Tracing, controlled by "--trace-file" and "--trace"
• Logging, controlled by "--log-file" and "--log-level"
• Debugger disasm/memdump/registers output, controlled by "logfile"
• xconout redirection [2] and Hatari command line help, hard-coded to stdout
• Rest of debugger (breakpoints etc) and rest of Hatari output, hard-coded to stderr

With first 3 defaulting to stderr. There are also some (stdout) prints sprinkled around Hatari code, but I'm looking whether those should all also go to stderr, and documenting the above list.

[2] included to "os_base" and "os_all" trace options for VT52 console, which can be enabled also without rest of tracing using "--conout 2" option.

[czietz]

(I'm not sure whether output redirection can be easily done on Windows though

Of course it can be easily done. E.g., ...

hatari.exe 2> log.txt

... to only redirect stderr and

hatari.exe > foo.txt 2>&1

... to redirect stdout and stderr.

[Eero Tamminen]

(I'm not sure whether output redirection can be easily done on Windows though

Of course it can be easily done. E.g., ...

hatari.exe 2> log.txt

... to only redirect stderr and

hatari.exe > foo.txt 2>&1

... to redirect stdout and stderr.

Is that normal Windows terminal or does one need e.g. to install Cygwin / Bash?

[czietz]

Is that normal Windows terminal

Of course. Why are you so surprised?
https://docs.microsoft.com/en-US/troubl ... and-prompt

EDIT: But I forgot one important detail! I always use Hatari as a console application under Windows. (I don't like the way its delivered as a GUI application by default.) Therefore I have setup my own builds accordingly and official builds are modified with a hex editor: https://listengine.tuxfamily.org/lists. ... 00002.html.

EDIT2: But it also works the same with the default "GUI" setting for hatari.exe.

[Eero Tamminen]

I was surprised because I haven't had to really use Windows for a long time, especially from console, and Windows terminal was DOS based for so long (in 90's), and really sucked because of that. They did that PowerShell thing around 2006, but I understood that to have its own (more object oriented) syntax. Nice to hear that unix conventions work nowadays on Windows too.

Even nicer would be if unix sockets and FIFOs would also work, so that Hatari remote control APIs could be used...

PS. At home I've never had Windows, but I do have a Windows laptop at work even now, to change Windows AD password (have had bad experience trying to do that from Linux), and to use some odd web thing now and then where corporate infra is too broken to support standards and Linux (e.g. some commercial web-based service requiring so old crypto that support for it is dropped from latest Fedora for security reasons). Switching between USB headsets in Microsoft Teams seems to work better under Windows than Linux, but I think that's a Teams issue, not Linux one.