Re: [hatari-devel] trace output format |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
On sunnuntai 11 elokuu 2013, Nicolas Pomarède wrote:
> On 10/08/2013 19:13, Eero Tamminen wrote:
> > IMHO if there are common fields in different traces, I think they
> > should be at the start of the trace with fixed widths, so that they
> > get aligned. That makes reading traces with lots of similar lines
> > easier.
> >
> > Only common field in IO trace is PC address, that's why I added it at
> > the start, with fixed width.
>
> Without requiring to have a fixed length (which can make trace file
> unnecesseray big when using "--trace all" due to all the added
> "spaces"),
With today's GB sized disks, I don't think the small space increase
is a problem. I've never had problems with the space the traces
take, just with finding the relevant data from them.
> the fact to have it in the 1st column seems enough to me if
> you want to do manipulations later on a full log file to filter some
> lines (having the trace type in the 1st column is easy to get with "grep
> ^xxxxxx" or with awk '{print $1}')
You can use "grep ': xxxx'" and "awk '{print $2}'" instead.
> As not all traces need a PC, I think it should be kept at the end of the
> line.
>
> > Because PC address info is useful with most (all?) of the traces,
> > my counter-proposal is that it would be output automatically by
> > LOG_TRACE() macro, to the start of the trace line, and removed
> > from current LOG_TRACE() call sites.
>
> I don't think PC address should be automatically added in traces. Some
> traces are not related to a cpu's action. For example, aci, ikbd, fdc,
> blitter or dma sound can generate traces on their own without a cpu
> instruction being involved.
While not as relevant as instruction triggering it, it might still be
somewhat relevant to know at which instruction they happened.
> LOG_TRACE is also used in DSP, where no cpu PC is available, so getting
> PC values inside LOG_TRACE is not necessary someting straight forward.
Converting them to use separate LOG_TRACE_CPU and LOG_TRACE_DSP
macros would be trivial.
> So, I'd rather keep log_trace as simple as it is now and leave it to
> each component to choose the necessary level of details it wants to
> display.
I'm not convinced, but if you really want to change it, go ahead. :-)
- Eero