On 3/25/24 13:58, Peter Maydell wrote:
On Mon, 25 Mar 2024 at 06:41, Pierrick Bouvier
<pierrick.bouv...@linaro.org> wrote:
On 3/25/24 10:06, Yao Xingtao wrote:
diff --git a/contrib/plugins/execlog.c b/contrib/plugins/execlog.c
index a1dfd59ab7..09654910ee 100644
--- a/contrib/plugins/execlog.c
+++ b/contrib/plugins/execlog.c
@@ -327,8 +327,13 @@ static GPtrArray *registers_init(int vcpu_index)
for (int p = 0; p < rmatches->len; p++) {
g_autoptr(GPatternSpec) pat =
g_pattern_spec_new(rmatches->pdata[p]);
g_autofree gchar *rd_lower = g_utf8_strdown(rd->name, -1);
+#if GLIB_CHECK_VERSION(2, 70, 0)
+ if (g_pattern_spec_match_string(pat, rd->name) ||
+ g_pattern_spec_match_string(pat, rd_lower)) {
+#else
if (g_pattern_match_string(pat, rd->name) ||
g_pattern_match_string(pat, rd_lower)) {
+#endif
Register *reg = init_vcpu_register(rd);
g_ptr_array_add(registers, reg);
As suggested by Peter on previous version, you can declare a new
function `g_pattern_match_string_qemu` in include/glib-compat.h which
abstract this.
We should have an abstraction function, but it should *not*
be in glib-compat.h, but local to this plugin's .c file. This is
because the plugins are deliberately standalone binaries which do not
rely on any of QEMU's include files or build process (you'll
see they don't use osdep.h, for example).
Sorry, I misunderstood that, as it was discussed with Alex that maybe
plugins should be able to access glib-compat.h.
thanks
-- PMM
