Attached updated patch-set handles cases mentioned at the bottom of the
mail (repeat messages are flushed before direct / multi-line output to
trace file), and it adds autoscaling to the repeat limit, so CLI option
is now just toggle.
I'm considering this good enough to be pushed to Hatari unless somebody
has objections within week or two.
It would be nice if somebody using CPU disasm tracing could first verify
that my changes are not messing it though.
- Eero
PS. NetBSD 8.2 startup with CPU symbol and IDE tracing looks like
following with it:
------------------------------------------------
hatari --netbsd -c netbsd.cfg --monitor vga --machine falcon --dsp none
--mmu on -s 14 --ide-master 8mb-disk.img --disk-a blank-a.st --parse
profile.ini --trace ide
DOS MBR:
- Partition 0: type=0x04, start=0x00000001, size=8.0 MB (boot)
- Partition 1: type=0x00, start=0x00004000, size=0.0 MB (invalid)
- Partition 2: type=0x00, start=0x00004000, size=0.0 MB (invalid)
- Partition 3: type=0x00, start=0x00004000, size=0.0 MB (invalid)
- Total size: 8.0 MB in 1 partitions
IDE: little->big endian byte-swapping enabled for drive 0
IDE: using geometry LCHS=16 16 63
NetBSD: kernel_phdrs[0].p_vaddr = 0x00000000
NetBSD: kernel_phdrs[0].p_offset = 0x00000080
NetBSD: kernel_phdrs[0].p_filesz = 0x002777ac
NetBSD: kernel_phdrs[0].p_memsz = 0x00292de0
NetBSD: Copying segment 0: 0x00000080,0x002777ac to 0x00002000-0x002797ac
NetBSD: Copying symbol strings: 0x002fc2d6,0x000000d3 to
0x002950e4-0x002951b7
NetBSD: Copying symbol table: 0x00280884,0x0004df50 to
0x002951b8-0x002e3108
NetBSD: Copying symbol strings: 0x002ce7d4,0x0002db02 to
0x002e3108-0x00310c0a
WARNING: removed 6315 complete symbol duplicates
Loaded 12883 symbols (9299 TEXT) from 'kernel'.
Machine info:
ST-RAM size : 4194304 bytes
TT-RAM size : 0 bytes
TT-RAM start : 0x01000000
Cpu-type : 0x00001008
Kernel loadaddr : 0x00002000
Kernel size : 3206156 (0x30ec0c) bytes
Kernel entry : 0x000027da
Kernel esym : 0x0030ec0c
Reading debugger commands from 'profile.ini'...
> trace cpu_symbols
Lstart2
8 repeats of: Lstart2
16 repeats of: Lstart2
32 repeats of: Lstart2
64 repeats of: Lstart2
128 repeats of: Lstart2
256 repeats of: Lstart2
512 repeats of: Lstart2
1024 repeats of: Lstart2
2048 repeats of: Lstart2
4096 repeats of: Lstart2
8192 repeats of: Lstart2
16384 repeats of: Lstart2
32768 repeats of: Lstart2
65536 repeats of: Lstart2
131072 repeats of: Lstart2
262144 repeats of: Lstart2
274698 repeats of: Lstart2
Lstart3
Lend_cpuset
start_c
badbaddr
setjmp
longjmp
badbaddr
setjmp
...
------------------------------------------------
On 29.10.2022 0.47, Eero Tamminen wrote:
on suggestion from Uwe, I've extended this code to cover also log
messages in addition to trace output.
Patches attached. Any comments?
(see limitations below.)
On 28.8.2022 23.49, Eero Tamminen wrote:
I've had a problem with tracing that some programs hit specific trace
point constantly, either as result of bug, or as their normal
working, which can scroll the relevant (other) output from console
view and scroll buffer near-instantly.
Attached are patches to change tracing so that one can specify
whether trace output will compress repeated lines, and how many
successive repeats there needs to be for it to output intermediate
info about the repeats.
I'm mapping also LOG_TRACE_PRINT() macro to this, but there are few
traces where this falls down:
- IDE ATAPI CMD
- NF_SCSIDRV inout
Because they do multiple lines of output.
Then there are few things that access TraceFile directly for
multi-line output (instead of using LOG_TRACE_PRINT macro):
- CPU + DSP disasm tracing
- CPU + DSP register tracing
- AES tracing
I.e. one should not enable trace compression when tracing one of
above 7 items is enabled.
Comments / thoughts?