Support for us floating point timestamps generated by Incisive

[thomasfrimannkoren]

Hey!
We were doing some simulations of a Cortex M0+@108mhz in Cadence Incisive and noticed that the produced tarmac-file couldn't be parsed by the trace-utilities.
The trace-file contains µs-level timestamp as floating point literals. I just ham-fisted a solution where I convert the floating point timestamps to integers.

The tarmac-files from incisive looks like this:

       1166.141000us E HRESETn 1
       1166.177000us MR4_D 00000000 00204800
       1166.177000us R MSP 00204800
       1166.187000us MR4_D 00000004 0000010b
       1166.196000us R PSR f1000000
       1166.196000us E ATOMIC 0
       1166.205000us MR2_I 0000010a b5100000
       1166.214000us MR4_I 0000010c ffdaf7ff
       1166.214000us IT 0000010a b510        PUSH     {r4,lr}
       1166.223000us MW4_D 002047f8 ffffffff
       1166.232000us MW4_D 002047fc ffffffff
       1166.232000us R MSP 002047f8
       1166.250000us IT 0000010c f7ffffda    BL       {pc} - 0x48  ; 0xc4

[statham-arm]

Thanks for the patch!

Before I accept it, could you append the test lines from the commit message to tests/parsertest-implicit-thumb.txt, with a comment mentioning their origin? Then run this command to update the expected output:

parsertest --implicit-thumb tests/parsertest-implicit-thumb.txt > tests/parsertest-implicit-thumb.ref

and include both changes in the patch.

That way, if we need to refactor this code later, we'll have a regression test. Also it will check we don't break anything else about that specific format of Tarmac.

[thomasfrimannkoren]

Hey Simon!
Thanks for the quick review :-)

I updated the parsertest as requested. Please tell me if there is anything else you'd like me to do for this to be accepted.

[statham-arm]

No, that's everything. Thanks very much for the patch!