[Bug tapsets/18769] [ppc64BE/--dyninst] unknown operator @__compat_task

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

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

--- Comment #2 from Martin Cermak <mcermak at redhat dot com> ---
The separation of /linux and /dyninst directories is apparently quite
intentional:

=======
$ grep -A 21 'add empty string as last element' main.cxx  | nl
     1    // add empty string as last element
     2    version_suffixes.push_back ("");

     3    // Add arch variants of every path, just before each
     4    const string& arch = s.architecture;
     5    for (unsigned i=0; i<version_suffixes.size(); i+=2)
     6      version_suffixes.insert(version_suffixes.begin() + i,
     7                              version_suffixes[i] + "/" + arch);

     8    // Add runtime variants of every path, before everything else
     9    string runtime_prefix;
    10    if (s.runtime_mode == systemtap_session::kernel_runtime)
    11      runtime_prefix = "/linux";
    12    else if (s.runtime_mode == systemtap_session::dyninst_runtime)
    13      runtime_prefix = "/dyninst";
    14    if (!runtime_prefix.empty())
    15      for (unsigned i=0; i<version_suffixes.size(); i+=2)
    16        version_suffixes.insert(version_suffixes.begin() + i/2,
    17                                runtime_prefix + version_suffixes[i]);

    18    // First, parse .stpm files on the include path. We need to have the
    19    // resulting macro definitions available for parsing library files,
$
=======

I tried to add /linux into version_suffixes, but many tapsets dedicated for
kernel runtime are unusable for dyninst runtime, and at the end of the day -
it's understandable.

So maybe moving the macro definition from syscalls.stpm one level up in the
directory structure to e.g. compat_task.stpm, where it would be consumed by
both runtimes, might be a way to go.

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