Tools for analyzing and browsing Tarmac instruction traces.

I build the binaries on Windows using visual studio 2017 as mentioned and when i try to get the profile information for large tarmac trace files (>1.5GB), the tools crash during indexing and it refers me towards this line: https://github.com/ARM-software/tarmac-trace-utilities/blob/main/lib/calltree.cpp#L247

I would like to understand if there is a limitation on how big the trace file can be?

Hi, Sorry to bother you! I'm learning tarmac based sw debug and just found this project which is quite useful. However, before fully understanding the implementation, I have a very initial question/confusion about the fundamental implementation of index file and how it being used by other tools. For example, I tried play tarmac-browser, it immediately shows reg and memory info once I jump to certain line of original tarmac file. It seems the reg/memory info of certain tarmac line is stored in the index file so that it can be represented in browser immediately (like, the reg/memory info at that moment of each line in the trace are stored). But in theory, it's almost impossible to store such huge info in the index file (and I see the size of index file looks OK). I'm wondering, if index file only contains intermediate info, then other tools like browser still need kind of processing to get reg/memory info of certain line of trace? If so, what if the size of original tarmac trace is large (for example, GB level), despite of the index generation time, any potential performance risk when browser to represent info? Thank you!

Hi,

I am trying to parse a tarmac log generated from a run and I am getting the following error:

tarmac_example_for_github_issue.log:7: unknown Tarmac event type 'MNR4___I' tarmac_example_for_github_issue.log:8: unknown Tarmac event type 'BNR4___I' tarmac_example_for_github_issue.log:12: unknown Tarmac event type 'MNR4O__I' tarmac_example_for_github_issue.log:13: unknown Tarmac event type 'BNR4O__I' tarmac_example_for_github_issue.log:16: expected ')' after bracketed value 3027 cyc IT (00022ad6:00000000) 00022ad6 48e2 T16 LDR r0,[pc,#904] ; [0x22e60]

tarmac_example_for_github_issue.log

BR Nick

tarmac-browser doesn't like the following entry:

2884500 ps ES (0000000000000188:9e6703e0) O el3h_s: FMOV d0,xzr R V0<63:0> 0000000000000000 R V0<127:64> 0000000000000000

$ ./tarmac-browser tarmac._CLUSTER_g_core_0__g_little_u_helios_core_u_vcpu_u_cpu_u_helios_dpu_u_follow_.t0.log 
index file tarmac._CLUSTER_g_core_0__g_little_u_helios_core_u_vcpu_u_cpu_u_helios_dpu_u_follow_.t0.log.index does not exist; building it
tarmac._CLUSTER_g_core_0__g_little_u_helios_core_u_vcpu_u_cpu_u_helios_dpu_u_follow_.t0.log:199: Unrecognised token
                    R V0<63:0> 0000000000000000
                        ^

I tried to build using the commands suggested in the readme, but "cmake ." fails with an error message suggesting a bug in CMakeLists.txt:

$ cmake .
-- The CXX compiler identification is GNU 7.5.0
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found Curses: /usr/lib/x86_64-linux-gnu/libcurses.so  
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1") 
-- Checking for module 'gtk+-3.0'
--   Found gtk+-3.0, version 3.22.30
CMake Error at CMakeLists.txt:46 (install):
  install TARGETS given target "tarmac-callinfo" which does not exist in this
  directory.


-- Found PythonInterp: /usr/bin/python3 (found version "3.6.9") 
-- Configuring incomplete, errors occurred!
See also "/home/petmay01/src/tarmac-trace-utilities/CMakeFiles/CMakeOutput.log".

This is on an Ubuntu 18.04.5 LTS with cmake version 3.10.2.

I don't see anything obviously diagnostic in the CMakeOutput.log but I have attached it anyway. CMakeOutput.log

This flavour of Tarmac is approximately in the Fast Models style (IT/IS instruction records, contiguous rather than diagrammatic memory transfers), but with some awkward differences that aren't clearly signalled: the CPU mode field is missing from instruction records, and the data in memory transfers is given in memory order rather than logical order.

As far as I can tell, these changes manage to support this format without either breaking the existing test suite or requiring an up-front mode setting for the Tarmac parser. But it's precarious: the clues from which I deduce which syntax and semantics to expect don't really have much to do with the syntax and semantics differences, so it's all a bit more 'recognise the fingerprint of a particular implementation' than I'd like.

However, it does work, and this change also adds some Cortex-M4 lines to the parser test suite with their expected output. So if we need to completely rethink things later, we'll be able to make sure the new approach still works.

This commit sets up 4 worflows, to configure, build and test tarmac-trace-utilities on Ubuntu 18.04, Ubuntu 20.04 with gcc and clang.

The current status of the CI is shown at the top of the README.rst.

The documentation at https://cmake.org/cmake/help/latest/command/link_directories.html explicitely states :

The command will apply only to targets created after it is called, so fix the invocation order in the CMakeLists.txt.

While being there, remove the 'PRIVATE' keyword which does not apply to this flavour of the linker command setup.

This does fix building tarmac-gui-browser on Mac and remove spurious warnings about non-existing xyz/PRIVATE directories.

From the Note in the CMake manual (https://cmake.org/cmake/help/latest/command/link_directories.html) the link_directories command is rarely necessary. It's rather suggested to use target_link_libraries with the full pathes for the libraries. pkg-config conveniently sets this with ${GTK_LINK_LIBRARIES}.

This does fix building tarmac-gui-browser on Mac.

We're currently tracing our boot ROM and bootloader, and we're jumping between several ELF: BL1, BL2, BL31 & BL33. We would like to have the option to supply multiple ELF files. Is it possible ?

I'm playing around with tarmac-browser as an alternative to my traditional "just view the trace file with less" approach, and one feature I would really like is the ability to move around in the trace by arbitrary text search. In 'less' you can do this with:

• /pattern to search forwards
• ?pattern to search backwards
• n to repeat the previous search

This lets you do ad-hoc things like "find the first VLDR in the trace", or "find the last point in the trace where some register had the value 0x8080". (Less critically, it also means I don't have to get used to a different interface for "go to this PC", because /3901bd80 would then work for that just as it does in less.)