|
Hi Zied
About your question: "what if, for prototyping purpose, we assign a "fake" timing of 1 unit of time per function segment? to give a time stamp to each entry? is there a sample code that parses a similar textual input and display it? "
The data flow in Trace Compass starts always with a trace parser that provides trace events. If you implement a parser for your trace format, you will have control on the timestamp each event returns. So, for each function, you could create an enter event with
timestamp1 and exit event with timestamp2 where timestamp2 > timestamp1. Each event has a payload, in Trace Compasses terms event fields, where you can attach other relevant data.
In the Trace Compass developer guide, there is an example on how to create a trace parser:
In Trace Compass there are different trace parsers implemented for different trace formats. All of them extend the class TmfTrace. You can search for all the class that extends TmfTrace.
For traces in text format, class TextTrace is good starting point. It parses trace events using regular expressions.
Once you have the parser you can open the trace in Trace Compass and you will see the detailed events list (events table) and some common views e.g. event statistics and histogram.
For other application specific views, you will have to implement analysis and views. The basics are described in the developer guide:
For populating a Flame Chart you will need to create an analysis (as described above) and extend class CallStackAnalysis as analysis class and implement the abstract methods.
See example LttngUstCallStackAnalysis for reference:
The description above is simplified but it should help to get you started. Maybe start with the trace parser and open it in Trace Compass to see the data in events table. After that you can tackle the analysis.
Good luck!
BR
Bernd Hufmann
From: tracecompass-dev <tracecompass-dev-bounces@xxxxxxxxxxx> on behalf of tracecompass developer discussions <tracecompass-dev@xxxxxxxxxxx>
Sent: February 1, 2021 5:33 PM
To: tracecompass developer discussions <tracecompass-dev@xxxxxxxxxxx>
Subject: Re: [tracecompass-dev] using trace compass view gdb branch tracing ->functions and instructions histories
Hi Bernd,
thanks for your answer.
concerning the timing, actually intel Pt and ARM ETM can provide "cycle accurate" timing information. those are currently not used in branch tracing, but gdb can be extended to include them.
what if, for prototyping purpose, we assign a "fake" timing of 1 unit of time per function segment? to give a time stamp to each entry? is there a sample code that parses a similar textual input and display it?
Kind Regards
Zied Guermazi
On 01.02.21 19:57, tracecompass developer discussions wrote:
Hi Zied,
thanks for your interest in Trace Compass. Sorry for the late reply, I meant to answer earlier.
To answer your questions:
> Is it possible to display function calls history as a flame chart
The flame chart by default depends on a timing analysis module that reads trace event from a trace, keeps track of function enter and return events and stores the function duration for each function. Each function enter and return event requires a timestamp.
There are API for the timing analysis in Trace Compass that can be extended, and which will populate the flame chart. With the current API it's not (or only with many hacks) to display the function call history as you described in the flame chart.
> ...and instruction history as an event list
It is be possible to populate the events table with instruction history. However, you need to create a parser for the event list that acts as trace reader and which provides each instruction as event. Usually, events have a timestamp, a type and payload. If
you don't have the timestamp, then the events table is purely working with the event order (rank). All other Trace Compass views are based on time and hence you won't be able to use all the time depended features which is the strength of Trace Compass.
Trace Compass already provides GDB Tracepoint analysis which can be installed separately from the Trace Compass update sites. Users can define GDB Tracepoints, collect some data while running the application and when hitting the tracepoints (variable, registers
etc.), and then store that data in a trace file. Trace Compass can parse this trace file and populate the events table with the data using GDB as parser. The events table is synchronized with some debug views, e.g. selecting an event will populate the variable
view with the tracepoint data and vice-verca. Since, by default, no time information is collected, then the GDB Tracepoints - Trace Compass integration is limited. Collecting the time information and make use of it, could have been an improvement for the GDB
Tracepoint feature in Trace Compass, but we've never got to it.
So, the GDB Tracepoint integration sounds similar to what you asked about showing instruction history in the event list. You could have look in the org.eclipse.tracecompass.gdbtrace.core/org.eclipse.tracecompass.gdbtrace.ui plug-in of the Trace Compass repository.
I hope this information helps.
Best Regards
Bernd Hufmann
hi
GDB branch tracing offer function and instruction histories, function history generate a "call graph" of functions over time, here is an example:
(gdb) record function-call-history /ilc 1
1 main inst 1,8 at function_call_history.c:40,41
2 inc inst 9,19 at function_call_history.c:22,24
3 main inst 20,31 at function_call_history.c:40,41
4 inc inst 32,42 at function_call_history.c:22,24
5 main inst 43,54 at function_call_history.c:40,41
6 inc inst 55,65 at function_call_history.c:22,24
7 main inst 66,77 at function_call_history.c:40,41
8 inc inst 78,88 at function_call_history.c:22,24
9 main inst 89,100 at function_call_history.c:40,41
10 inc inst 101,111 at function_call_history.c:22,24
11 main inst 112,123 at function_call_history.c:40,41
12 inc inst 124,134 at function_call_history.c:22,24
13 main inst 135,146 at function_call_history.c:40,41
14 inc inst 147,157 at function_call_history.c:22,24
15 main inst 158,169 at function_call_history.c:40,41
16 inc inst 170,180 at function_call_history.c:22,24
17 main inst 181,192 at function_call_history.c:40,41
18 inc inst 193,203 at function_call_history.c:22,24
19 main inst 204,215 at function_call_history.c:40,41
20 inc inst 216,226 at function_call_history.c:22,24
21 main inst 227,238 at function_call_history.c:40,43
22 fib inst 239,249 at function_call_history.c:28,32
23 fib inst 250,262 at function_call_history.c:28,33
24 fib inst 263,267 at function_call_history.c:32
25 fib inst 268,278 at function_call_history.c:28,32
26 fib inst 279,291 at function_call_history.c:28,33
27 fib inst 292,296 at function_call_history.c:32
28 fib inst 297,309 at function_call_history.c:28,33
29 fib inst 310,315 at function_call_history.c:32,33
30 fib inst 316,321 at function_call_history.c:32,33
31 main inst 322,326 at function_call_history.c:43,44
(gdb)
instruction history generate a list of assembly instructions that were executed with mapping to the source code. here is an example
function_call_history.c:33 }
259 0x000103e4 <fib+44>: mov r0, r3
260 0x000103e6 <fib+46>: adds r7, #12
261 0x000103e8 <fib+48>: mov sp, r7
262 0x000103ea <fib+50>: pop {r4, r7, pc}
263 0x000103d4 <fib+28>: mov r4, r0
264 0x000103d6 <fib+30>: ldr r3, [r7, #4]
265 0x000103d8 <fib+32>: subs r3, #1
266 0x000103da <fib+34>: mov r0, r3
267 0x000103dc <fib+36>: bl 0x103b8 <fib>
function_call_history.c:28 {
268 0x000103b8 <fib+0>: push {r4, r7, lr}
269 0x000103ba <fib+2>: sub sp, #12
270 0x000103bc <fib+4>: add r7, sp, #0
271 0x000103be <fib+6>: str r0, [r7, #4]
function_call_history.c:29 if (n <= 1)
272 0x000103c0 <fib+8>: ldr r3, [r7, #4]
273 0x000103c2 <fib+10>: cmp r3, #1
274 0x000103c4 <fib+12>: bgt.n 0x103ca <fib+18>
function_call_history.c:32 return fib(n-2) + fib(n-1);
275 0x000103ca <fib+18>: ldr r3, [r7, #4]
276 0x000103cc <fib+20>: subs r3, #2
277 0x000103ce <fib+22>: mov r0, r3
278 0x000103d0 <fib+24>: bl 0x103b8 <fib>
function_call_history.c:28 {
279 0x000103b8 <fib+0>: push {r4, r7, lr}
280 0x000103ba <fib+2>: sub sp, #12
281 0x000103bc <fib+4>: add r7, sp, #0
282 0x000103be <fib+6>: str r0, [r7, #4]
function_call_history.c:29 if (n <= 1)
283 0x000103c0 <fib+8>: ldr r3, [r7, #4]
284 0x000103c2 <fib+10>: cmp r3, #1
285 0x000103c4 <fib+12>: bgt.n 0x103ca <fib+18>
function_call_history.c:30 return n;
286 0x000103c6 <fib+14>: ldr r3, [r7, #4]
287 0x000103c8 <fib+16>: b.n 0x103e4 <fib+44>
is it possible to display function calls history as a flame chart, and instruction history as an event list? what do we need to interface it to gdb and get a smooth transition between debug view and trace comapss view?
Kind Regards
Zied Guermazi
--
Zied Guermazi
founder
Trande UG
Leuschnerstraße 2
69469 Weinheim/Germany
Mobile: +491722645127
mailto:zied.guermazi@xxxxxxxxx
Trande UG
Leuschnerstraße 2, D-69469 Weinheim; Telefon: +491722645127
Sitz der Gesellschaft: Weinheim- Registergericht: AG Mannheim HRB 736209 - Geschäftsführung: Zied Guermazi
Confidentiality Note
This message is intended only for the use of the named recipient(s) and may contain confidential and/or privileged information. If
you are not the intended recipient, please contact the sender and delete the message. Any unauthorized use of the information contained in this message is prohibited.
_______________________________________________
tracecompass-dev mailing list
tracecompass-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/tracecompass-dev
--
Zied Guermazi
founder
Trande UG
Leuschnerstraße 2
69469 Weinheim/Germany
Mobile: +491722645127
mailto:zied.guermazi@xxxxxxxxx
Trande UG
Leuschnerstraße 2, D-69469 Weinheim; Telefon: +491722645127
Sitz der Gesellschaft: Weinheim- Registergericht: AG Mannheim HRB 736209 - Geschäftsführung: Zied Guermazi
Confidentiality Note
This message is intended only for the use of the named recipient(s) and may contain confidential and/or privileged information. If you are
not the intended recipient, please contact the sender and delete the message. Any unauthorized use of the information contained in this message is prohibited.
|
