And since there are no external users now, just unexport it, ditto
for tag__print_decl_info.
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
Its up to its callers, that will be moot soon as tag__print will call
function__print and as it already prints the decl info it'll be just a matter
of making all the function__print callers call tag__print instead and then
function__print will be unexported.
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
We have to check for a possible alias (abstract origin attribute) and handle
that when we want the function name, if it is an alias, do the lookup and cache
the result in ->name, that after all doesn't have a value in the first place.
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
As they already look just for DW_TAG_structure_type. Also make it return a
struct tag to avoid having to cast it back and forth too much.
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
Out of struct typedef_tag, that now becomes the superclass of struct class, and
that also will be for struct enumeration, struct union_type and then finally
for struct struct_type, when struct class finally dies.
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
By having its own class, struct typedef_tag.
As it, as structs, unions and enums have a common part, the node and visited
fields, required when emitting its definitions there is an opportunity for
consolidation, that will be explored when adding the specific classes for
DW_TAG_enumeration & DW_TAG_union.
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
Almost mirroring the DWARF on-disk linkage on memory, more to come before
getting over these simplification refactorings.
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
And fix its usage in ctracer and pfunct, guess the cmake adoption
is still a little problematic...
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
Will be reused when handling DW_TAG_subprogram_type more comprehensively, in
the upcoming csets.
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
So far struct class was being used as the main data structure, switch to struct
tag, that already was the top of the tag hierarchy, being a struct class
ancestor, so reflect that and stop using struct class as the catch all class,
as a started DW_TAG_array_type tags are now represented by a new class, struct
array_type, reducing the size of struct class and reducing DW__TAG_array_type
instance memory usage.
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
And now we have --kprobes to specify where to find the kprobes struct
definitions, needed as we don't include any header files, emitting the needed
struct definitions, forward declarations when just pointers are used and also
for function prototypes.
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
So that we can extract bits from one and combine it bits from other instances,
like we'll do in ctracer, where we want to have a cus instance just to get the
kprobes definitions and forward declarations but not handle the methods in it.
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
Its needed after all, if we want to use EXPORT_SYMBOL_GPL'ed symbols such as
register_jprobe, etc :-)
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
So that we can build a module that doesn't uses #includes to get these
definitions.
More work to be done for enums, etc, but this already is enough for
ctracer to handle tracing the sk_buff methods in vmlinux.
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
Now ctracer manages vmlinux at least for struct sk_buff, more to come as tests
are made with other classes (structs).
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
Not struct class_member, that was not much of a problem, as the
initial layout is the same (struct tag).
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
In cu_emit_kprobes_table_iterator we were defining the jprobes[] table for each
object file, do it surrounding the cu__for_each_cu call.
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
So that we can load many object files, that is what the next csets will
do, to recursively look for files with debug info in a build tree, such
as the kernel one.
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
A class tracer, it looks for non-inline functions that receive as one of its
parameters a pointer to the specified "class" (a struct) and will generate a
kprobes kernel module, see the whole sequence in the README.ctracer file.
Next steps involve supporting kretprobes, inserting kprobes at each inline
"method" expansion, using relayfs, and eventually uprobes to make this useful
for userspace as well.
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>