So that one can get an skeleton from where a function can be
reimplemented, or a probe can be written to attach to a tracepoint.
Right now it will only expand the types for
struct/union/typedef/enumeration types, but it is a good start.
[acme@doppio pahole]$ pfunct --expand_types --function inet6_ioctl ipv6.ko > a.c
[acme@doppio pahole]$ echo "int main(void) { return 0; }" >> a.c
[acme@doppio pahole]$ gcc -Wall -g a.c -o a
[acme@doppio pahole]$ grep ^#include a.c
[acme@doppio pahole]$
No errors, no includes.
This is present in ctracer, where we don't want to _require_ any header
files, just the object file with the function we want to probe. From
there we get the function signature, and reconstruct the types needed to
access members of structs passed as parameters.
We still need to add padding to reconstruct __attribute__ alignment
effects.
Also, if we can detect what are the exact members accessed in the probe,
we can reconstruct just what is needed to access those members,
hopefully reducing the time needed for gcc to digest the resulting
source code. And also reducing the size of the output, which can
hopefully be interesting to help focus on what the probe is doing.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Basically a wrapper for ftype__fprintf(&function__proto, ...) for the
cases we want the prototype rendered to a buffer, not to a file.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Thanks to Dennis Lubert for bringing this to my attention, now tons of BRAIN
FART ALERTs are gone.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
From: Pavel Emelianov <xemul@sw.ru>
There are many places where the construction like
foo = list_entry(head->next, struct foo_struct, list);
are used.
The code might look more descriptive and neat if using the macro
list_first_entry(head, type, member) \
list_entry((head)->next, type, member)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
By just adding the typedefs to the CU where the subroutine type is defined.
Reported-by: Diego 'Flameeyes' Pettenò <flameeyes@gmail.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
By inlining them in the output when possible, that way we get context on where
the problem is, etc.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
While pahole allows you to exclude classes with a specified prefix (using
--exclude), it doesn't appear to be able to do the opposite - only show classes
with a specific prefix. I found I needed this for my own use of it, so here is
a patch to add this functionality.
Signed-off-by: Dave Rigby <davidr@transitive.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
For correctly created and completely parsed debugging information the type will
always be found, but as we still need to parse more tags and expecting
debugging information to be always correctly built is not sane... sprinkle some
asserts.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Confusing, just follow the previous behaviour of not emitting messages
when debugging information is not found. Scripts should just look at $?
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
This is trying to get CTF friendly, where bitfields are not stored in the
equivalent to the DW_TAG_member dwarf TAG, but on "base types" with bit sizes
different than the real in the DWARF sense, base types (char, long, etc).
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
In libdwarves.so well continue using DW_TAG_ entries and types for now, but its
becoming non-DWARF specific as will be demonstrated with the introduction of
ctf_loader.c in the upcoming csets.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
memdup() is only referenced from dwarves.c. This patch defines them
static. Further symbol hiding can be accomplished via GCC attributes:
Signed-off-by: Hagen Paul Pfeifer <hagen@jauu.net>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Almost halves the time spent on processing a x86_64 vmlinux. Good, we
have features, now lets have performance ;-)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
This will print which object files have a struct definition, i.e. not just a
forward declaration.
There are many cases in the Linux kernel where just a fwd decl would suffice or outright
unneeded includes that end up bloating the DWARF sessions and consequently making everybody
suffer with humongous kernel-debuginfo packages.
More automation is needed here, this time something like sparse seems to be
needed to check what is that a header file "provides" and what is that the C
files "requires", doing some depsolving to discover unneeded Requires, i.e.
include directives and some that are required but are only satisfied
indirectly, which is a recipe for problems down the line.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Found in at least a file (tcp_ipv6.c in the Linux kernel) built with gcc
version 4.3.0 20080130 (Red Hat 4.3.0-0.7).
Which seems to be in violation with DWARF3, but better be defensive and handle
that.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
If passed as the old file, all functions in the new file will appear as being
new, etc.
Suggested by Ilpo Järvinen.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
It will return NULL, this will be useful for codiff to use /dev/null as one of
the files being compared. And if you look for something in NULL, you better
get NULL, seems like a useful convention, huh?
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Speeding up the process, no need to check for changes in the same object file,
be it standalone or part of a multi-cu file.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Arnaldo Carvalho de Melo
Pavel Emelianov
Dave Rigby
Felipe Kellermann
Hagen Paul Pfeifer