By avoiding tsearch calls, checking if the decl_file for the current tag
is the same for the last one, which is likely.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Grrr, the previous commit has the other bits, and as I already pushed it
out publicly... <BROWN PAPER BAG ALERT!> here goes the rests. So much
for bissectability. Sigh.
But the regression test showed only one problem, in C++ code, that I'll
fix in the next commits.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
So that we can then decide in what hashtable we will add it, and this
also paves the way for a type array that will help us in reducing the
size of struct tag by removing the id field.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
And comment the difference to tag__is_type:
tag__is_type == is this tag derived from the 'type' class?
tag__is_tag_type == is this tag a possible type for a tag, i.e.
one we will find in struct tag->type?
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Consider this case:
$ codiff -V /tmp/pahole.old build/pahole
/home/acme/git/pahole/pahole.c:
struct tag | +0
refcnt
removed: uint16_t /* 56( 0) 2( 0) */
recursivity_level
from: uint16_t /* 58( 0) 2( 0) */
to: uint16_t /* 56( 0) 2(15) */
used
added: uint16_t /* 56(15) 2( 1) */
1 struct changed
The number of members is the same and so is the size of the struct, but
'refcnt' was removed (in fact renamed to used) and 'used' was added.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Unfortunately the most common DWARF and CTF encoders don't agree on how
the names of base types are formed, so look for an alternative name.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
As most of the types comes with it already. Perhaps this was an
oversight and we will have to look if the name already has "char",
concat'ing only if it doesn't. We'll see...
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The dwarves were implemented first for DWARF, so all the algorithms work
with class_member ->bit_size, ->bit_offset and expect the ->offset field
to be the same for all members of a bitfield, so fixup these fields
after loading a CTF section.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Needed for CTF, where we can have many base types with name "unsigned",
but with different bit sizes, to implement bitfields.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Now we just pass a NULL terminated array of filenames, since we got rid
of that ugly -e insertion hack.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Now we use dwfl_report_offline directly, having more control about the
whole process, not using anymore dwfl_standard_argp.
This also, semi magicly, makes it work with the built-in.o files
in the Linux kernel, that aggregates multiple object files and that
previously were failing with relocation problems.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
This is still ugly, as the processing of argp was done on the loader so
that we can use the libdwfl argp processing, doing the tool argp
processing as a child. But then when we find out that there is no DWARF
info we fall back to another debugging format, with CTF being the only
other one supported as of now.
I used this scheme as when developing the CTF decoder and using pahole
on a binary with both CTF and DWARF info I would like to get the CTF
processed first.
So we still need some good refactoring here to get this sorted out in a
way that the user can specify the order of decoding, and perhaps even
ask for decoding _both_ and comparing if the results are the same, i.e.
if the (potentially subset of) information decoded from the first (that
may have less information: CTF) is the same as decoded from the second
(DWARF, more verbose).
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
So that they appear on the output in the same order as they
come from the original debugging info.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
And make the dwarves use it, so that we can remove duplicate strings in
a multi-CU file (vmlinux anyone?) and have it ready for insertion in a
compressed DWARF format with just the types, or better, CTF or some new
compressed debugging info format.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Arnaldo Carvalho de Melo