FR Inspection of individual trace events with their respective parameters

[maxthi]

I am recording sys_enter_futex_time32 and sys_exit_futex_time32 events and I am interested in the call parameters, so that I can better understand which futexes are locked/unlocked.

Recording with perf record -e syscalls:sys_enter_futex_time32,syscalls:sys_exit_futex_time32 -o perf.data and printing to a log with perf script -i perf.data > perf_script.log I can see these parameters. It would be nice to see them in Hotspot too.

Thanks for the tool, it's incredible useful.

[milianw]

Indeed, a table view for trace events with arguments would be nice to have. I don't think that is useful for samples though, or? I updated the title accordingly

[maxthi]

Maybe I am using the wrong terminology but what I am thinking of is the following. I have a few distinct events, like so

and now I would like to see the parameters that are associated with this event, because in the highlighted case, I would like to know which mutex address was used for sys_enter_futex_time32.

For a single sample it would probably be enough to show the params in the tooltip/popup, but with more samples/traced events, a table view might be better.

I could spend a bit of time on a contribution. Could anyone with knowledge of the codebase make an estimate how much work would be involved to make parameters visible?

[milianw]

I cannot give you such an estimate without spending more time on this myself. we'd need to understand how tools like perf script are doing the stringification. if it's easy then this is not very hard, if that requires custom bespoke heuristics it might turn out very hard. the initial support should be pretty easy though:

you'd have to read the remaining data from the TracePointSample, see this code in our parser:

            if (static_cast<EventType>(eventType) == EventType::TracePointSample)
                return true; // TODO: read full data

the following data is written in perfunwind.cpp from our perfparser submodule/dependency, see:

    if (type == TracePointSample) {
        QHash<qint32, QVariant> traceData;
        const QByteArray &data = sample.rawData();
        const EventFormat &format = m_tracingData.eventFormat(eventFormatId);
        for (const FormatField &field : format.fields) {
            traceData[lookupString(field.name)]
                    = readTraceData(data, field, m_byteOrder != QSysInfo::ByteOrder);
        }
        stream << traceData;
    }

so, if you would just read this in and forward it to the GUI. then it becomes a question how to store the results efficiently, probably needs some interning here and there. then, ideally we'd find a way to put the data into the Data::Tracepoint and then we can reference it from there as appropriate, potentially with some wrangling (time matching? dunno yet) to get from Event to the Tracepoint in the timeline. But just having it in the latter would be enough for a nice table view, which can then also be filtered/selected based on the interaction with the timeline view, like our other views