[Bug translator/18115] probe-condition mistranslated for array expressions

["jlebon at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=18115

Jonathan Lebon <jlebon at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jlebon at redhat dot com

--- Comment #1 from Jonathan Lebon <jlebon at redhat dot com> ---
Created attachment 8188
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8188&action=edit
patch for PR18115

These issues are due to the on-the-fly code, which doesn't account for
condition variables being map values, which require the creation of tmpvars to
get. More specifically, there were two problems:

(1) c_tmpcounter was not visiting the conditions, causing a mismatch between
c_tmpcounter and c_unparser.

(2) The emit_probe_condition_initialize() function would cause this type of
code to be emitted right in the middle of systemtap_module_init():

  stap_probes[0].cond_enabled = !!(((
  ({
    l->__tmp11 = _stp_map_get_ii (global(s_foo), ((int64_t)0LL));
    l->__tmp11;
  })) == (((int64_t)0LL))));

which will fail to compile since we are not within any probe body and thus
there is no 'l'.

The patch above changes the initialization mechanism so that a begin probe is
used rather than evaluating the conditions in systemtap_module_init(). The
begin probe is registered as artificially affecting every other probes with
conditions and thus will directly serve to initialize cond_enabled fields
through the regular emit_probe_condition_update(). This also allows us to get
rid of emit_probe_condition_initialize().

Making sure right now that the patch doesn't cause any regressions.

-- 
You are receiving this mail because:
You are the assignee for the bug.