Export tracing records in rows instead of multi-line structures

[elfring]

Some tracing data are offered as data structures which are distributed over multiple lines.

Example:
Call and return information according to function executions

I suggest to provide corresponding values in a single row per data set on demand.

[iipeace]

could you explain more detailed examples that you imagine?

[elfring]

I became especially interested in efficient and safe analyses for function executions.
I guess that other trace reports would be similarly affected.
(Will the software documentation be improved accordingly?)

👀 I am looking for ways to combine available information (from some lines) into rows for further data processing approaches.

[iipeace]

Please share detailed output examples :)

[elfring]

I suggest to take another look at analysis examples which you published already.

[iipeace]

I guess that you wanna get a line including both function entry and return info.
Is it right?

[elfring]

Yes (for another concrete use case)

[iipeace]

What do you think about this?
It will only print return context.

# ./guider.py btrace yes -c "|filter:RETVAL:BT:0"

[elfring]

Such a functionality can occasionally be also useful.
I hope that the software documentation will be improved.

But it is obvious that the mentioned filter example does not combine discussed data items, isn't it?

[iipeace]

Yes, it doesn't combine function entry info.
But the combined output will not displayed until the target function call is finished(return). is it okay?

[iipeace]

What do you think about this output?

0.035559 write(1>/dev/null,0x55d092dbb440,0x2000)[/usr/lib/x86_64-linux-gnu/libc-2.31.so]=0x2000(8192)/0.000021 -> 0x4c40/0x55d092947000 [/usr/bin/yes]
0.035842 write(1>/dev/null,0x55d092dbb440,0x2000)[/usr/lib/x86_64-linux-gnu/libc-2.31.so]=0x2000(8192)/0.000021 -> 0x4c40/0x55d092947000 [/usr/bin/yes]
0.037240 write(1>/dev/null,0x55d092dbb440,0x2000)[/usr/lib/x86_64-linux-gnu/libc-2.31.so]=0x2000(8192)/0.000023 -> 0x4c40/0x55d092947000 [/usr/bin/yes]
0.046022 write(1>/dev/null,0x55d092dbb440,0x2000)[/usr/lib/x86_64-linux-gnu/libc-2.31.so]=0x2000(8192)/0.000021 -> 0x4c40/0x55d092947000 [/usr/bin/yes]
0.052150 write(1>/dev/null,0x55d092dbb440,0x2000)[/usr/lib/x86_64-linux-gnu/libc-2.31.so]=0x2000(8192)/0.000023 -> 0x4c40/0x55d092947000 [/usr/bin/yes]
0.082249 write(1>/dev/null,0x55d092dbb440,0x2000)[/usr/lib/x86_64-linux-gnu/libc-2.31.so]=0x2000(8192)/0.000022 -> 0x4c40/0x55d092947000 [/usr/bin/yes]
0.088081 write(1>/dev/null,0x55d092dbb440,0x2000)[/usr/lib/x86_64-linux-gnu/libc-2.31.so]=0x2000(8192)/0.000023 -> 0x4c40/0x55d092947000 [/usr/bin/yes]

[elfring]

But the combined output will not displayed until the target function call is finished(return). is it okay?

Yes ‒ for a configured software analysis variant (as proposed).

[elfring]

What do you think about this output?

The display looks promising.
I would like to know more about the data items which are provided in such rows.

[iipeace]

You can check a new feature with a below command.

$ ./guider.py btrace yes -c "write|getret" -q completecall

0.037839 write(0x1,0x558c8d83e440,0x2000,0x7f7728567640,0x558c8d83e440,0x7c)[/usr/lib/x86_64-linux-gnu/libc-2.31.so]=0x2000(8192)/0.000010 -> 0x4
0.037859 write(0x1,0x558c8d83e440,0x2000,0x7f7728567640,0x558c8d83e440,0x7c)[/usr/lib/x86_64-linux-gnu/libc-2.31.so]=0x2000(8192)/0.000010 -> 0x4
0.037879 write(0x1,0x558c8d83e440,0x2000,0x7f7728567640,0x558c8d83e440,0x7c)[/usr/lib/x86_64-linux-gnu/libc-2.31.so]=0x2000(8192)/0.000010 -> 0x4
0.037900 write(0x1,0x558c8d83e440,0x2000,0x7f7728567640,0x558c8d83e440,0x7c)[/usr/lib/x86_64-linux-gnu/libc-2.31.so]=0x2000(8192)/0.000010 -> 0x4
0.037920 write(0x1,0x558c8d83e440,0x2000,0x7f7728567640,0x558c8d83e440,0x7c)[/usr/lib/x86_64-linux-gnu/libc-2.31.so]=0x2000(8192)/0.000010 -> 0x4
0.037940 write(0x1,0x558c8d83e440,0x2000,0x7f7728567640,0x558c8d83e440,0x7c)[/usr/lib/x86_64-linux-gnu/libc-2.31.so]=0x2000(8192)/0.000010 -> 0x4
0.037960 write(0x1,0x558c8d83e440,0x2000,0x7f7728567640,0x558c8d83e440,0x7c)[/usr/lib/x86_64-linux-gnu/libc-2.31.so]=0x2000(8192)/0.000010 -> 0x4
0.037980 write(0x1,0x558c8d83e440,0x2000,0x7f7728567640,0x558c8d83e440,0x7c)[/usr/lib/x86_64-linux-gnu/libc-2.31.so]=0x2000(8192)/0.000010 -> 0x4
'''

[elfring]

Thanks for another positive feedback.
👀 I am still looking for corresponding extensions according to the software documentation.

[elfring]

I tried one of my small test programs out once more.

[Markus_Elfring@fedora guider]$ ./guider.py btrace '/home/altes_Heim2/elfring/Projekte/Bau/QStorageInfo-setPath/QStorageInfo-setPath' -c 'statvfs64|getret' -q completecall
… ver_3.9.8_211002 on python_3.9
…
"2 20:00:02.327" Determining file system: "/home/Markus_Elfring/gui_rpc_auth.cfg"
"2 20:00:02.368" | "Data determination by setPath()" | 5730828 |ns
"2 20:00:02.371" type name: "ext4"

1.878231 +++ exited QStorageInfo-se(72007) with 0 +++

Now I am missing the analysis data output according to your software update.