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



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/