ctf: store away the types and names of non-static global variables

ctf: store away the types and names of non-static global variables

The critical part of this change is assemble_ctf_variable(), which calls the new
ctf_add_variable() function to add a variable and its type information to the
appropriate CTF file (as determined by the deduplication pass).

Because we scan all scopes to detect non-opaque definitions of structures,
unions and enums used opaquely at global scope, and the functions called for
each DIE we understand tend to be quite expensive, we also introduce an
additional filtration mechanism (the 'assembly filter') to prevent DWARF tree
walks from calling an assembly function for DIEs we are not interested in.

We don't provide as much information to the assembly filter as to the assembly
function itself -- just the DIE and its parent DIE -- but that is enough to
prevent the assembly function from being called not only for variables but also
for base types, arrays, crv-qualified types, and pointer types at non-global
scope -- none of which we are interested in, since we care only about named
structures/unions/enums at non-global scope, and e.g.

typedef struct foo {
 ...
} *bar;

is represented as *three* DWARF nodes at the same level, one for 'struct foo',
one for a pointer to it, and one for a typedef of that.  So there is no danger
that avoiding processing for such types will miss the structures we are
interested in.

For variables, we filter out all 'uninteresting' types using a new filter
function which rules out not only 'variables' with no name, static variables,
and variables at non-global scope, but also a large number of specifically-
named global variables introduced by macros to cover facilities as diverse as
tracepoints and the kernel symbol table.  There is no chance that DTrace users
would want to look at these variables, so we don't need to store them in the
CTF.  (We don't need to consider points-to relationships for variables, unlike
types, so that consideration does not apply.)

DTrace userspace contains a similar list to avoid reading in uninteresting lines
from /proc/kallmodsyms, but the two need not be synchronized: CTF for variables
that DTrace is filtering out will simply never be consulted, and variables that
DTrace does not filter out but that have been filtered out by dwarf2ctf will
have no CTF and will simply be rejected at parsing time.

Signed-off-by: Nick Alcock <nick.alcock@oracle.com>