RE: [PATCH v10 08/10] btrace, linux: Enable ptwrite packets.

Metzger, Markus T via Gdb-patches
2023-08-09T09:49:01Z

Hello Felix,

>> >> >+#if (LIBIPT_VERSION >= 0x200)
>> >> >+ record_btrace_conf.pt.ptwrite = true;
>> >> >+#else
>> >> >+ record_btrace_conf.pt.ptwrite = false;
>> >> >+#endif
>> >>
>> >> Is there a way to get an error when attempting to install a custom
>> >> ptwrite filter when either GDB (via libipt) or the kernel does not
>> >> support PTWRITE?
>> >
>> >Good point. Unfortunately I don't see one with the current design.
>> >Currently we just cache the filter functions in python when one is
>> >registered. The configuration isn't exposed to the python layer in
>> >any way.
>> >
>> >I am not sure how we could do this. Exposing "maint btrace info"
>> >and parsing that would be one way, not sure if we want to go down
>> >that path.
>>
>> We could warn at decode-time when applying the ptwrite filter.
>> We should have different warning texts for GDB (via libipt) not
>> supporting ptwrite and the system (kernel or h/w) not supporting it.
>>
>> Not as good as an error when installing the ptwrite filter but better
>> than wondering why it isn't working as expected.
>
>Mhm, I don't see this either. We can't warn when we actually would
>apply the filter, as we never would get a ptwrite event.

I was referring to the apply_ext_lang_ptwrite_filter() call in ftrace_add_pt().

> As we don't
>enable ptwrite in Linux if libipt doesn't support it. And if libipt doesn't
>support it, we wouldn't get to that place in GDB in the first place,
>as there is an #ifdef protecting it.
>
>I looked at doing it when installing the extension language callback
>for ptwrite in btrace.c, e.g. something similar to this:
>
> /* Register the ptwrite filter. */
> if (btinfo->target->conf.pt.ptwrite)
> apply_ext_lang_ptwrite_filter (btinfo);
> else
> warning (_("Can't decode ptwrite events."));
>
>This we do regardless of libipt. But then we would get a warning
>regardless of the user trying to use ptwrite or not (with old libipt
>versions). Plus this doesn't compile, as struct btrace_target_info
>is forward declared, and we probably can't change that as btrace.c
>should be target independent.

We'd want the check inside gdbpy_load_ptwrite_filter(), which gets
called by apply_ext_lang_ptwrite_filter() to install the btrace callback.

This is GDB code so we should be able to check the libipt version as
well ask kernel support.

Regards,
Markus.