Need to read more on http://www.artima.com/cppsource/rvalue.html, but
handling it mostly like DW_TAG_typedef so that at least references to it
are resolved, we can get its byte size, etc.
FIXME: look at the vtable parameters, some are resolving to "(null)".
Reported-by: Benjamin Kosnik <bkoz@redhat.com>
Reported-by: Mark Wieelard <mjw@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=962571
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
As Thomas Gleixner wisely pointed out, using 'self' is stoopid, it
doesn't convey useful information, so use sensible names
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
.debug_types is a new DWARF 4 feature that adds some simple
compression to DWARF. The basic idea is that identical type
definitions are merged by the linker and put into a new .debug_types
section.
This introduces 'dwarf_off_ref', which is like Dwarf_Off, but carries
a flag indicating if the DIE came from .debug_types. This allows
future uses to find the DIE properly.
Type units are read a little differently from ordinary CUs. All type
units are read at once, then types are recoded for them. (I think
something like this is needed more generally, to support inter-CU
references, but I have not tried that.)
The type unit is also kept around longer, because any other CU may
refer to it. This necessitated a change to load_steal_kind to replace
the notion of a "stolen" CU with a request by the "stealer" for the
caller to delete the CU when appropriate.
I need elfutils patch 581c3f60e2b1fc7ddaf4260bb5a9cb59f8e3f0d0
to make this work properly; without it I see crashes.
You can make test cases by compiling with '-gdwarf-4 -fdebug-types-section'.
So make it a :4 u8 to combine with the previous bitfield. This field is
also seldom used so no expected perf hit.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Since we have two bytes after it in a hole, use them for vtable_entry,
hell knows if there isn't any crazy code with that many vtable
entries...
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
As we had 14 bits hole, so use them as bools, each taking one byte
but generating better/shorter code.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
[acme@doppio pahole]$ pahole -F ctf /media/tb/debuginfo/usr/lib/debug/usr/bin/greycstoration4integration.debug > /tmp/bla
<ERROR(tag__size:837): detected type loop: type=572, tag=const_type>
<ERROR(tag__size:837): detected type loop: type=572, tag=const_type>
[acme@doppio pahole]$
These type loops are problems in the CTF encoding, that should be fixed, but
should not cause the core code to segfault on an infinite recursion.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
That asks dwarf_fprintf to always use "struct" in places where it would
use "class", because CTF doesn't have the "class" concept, so for
'regtest diffctf' sake, we use this.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
That can happen, for instance, when the symtabs are NOBITS. When that
happened we ended up in an infinite loop. Call it earlier and check the
result.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
In the same fashion as DW_TAG_volatile_type, as we need to get to the
DW_TAG_base_type at the end of the chain.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
If it is C++ add DW_TAG_member entries to cu->tags_table and at
imported_declaration__fprintf fallback to cu__tag() if cu__function()
fails.
The right thing tho, long term, is to have a class for
"DW_TAG_imported_declaration" to register to what kind of tag this
points, if for DW_TAG_subprogram or to DW_TAG_member, the info is in the
DWARF DW_AT_import attribute, but so far we're not decoding it.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
It doesn't matter when using a traditional malloc/free allocator, but
with obstacks we need to do it in reverse order.
For the usual case where we successfully process an object this doesn't
matter, as when we started using obstacks we don't traverse all the tags
calling their destructors anymore, we just free the whole obstack in one
go.
Noticed when processing object files built from non-supported languages
such as FORTRAN and Pascal, where there are some DWARF tags that are not
supported, which makes the object file load to be prematurely aborted
and that calls destructors for things like classes and functions that in
turn free space for their parameter/member lists, which now have to be
done in reverse order.
We could just stop calling the destructors and then destroying the whole
obstack, but I think that partially processed files are a nice feature,
so keep the interface in a way that both obstacks and traditinal malloc
alocators can be used.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Adding an enum so that CTF doesn't have to include dwarf.h and
setting the language to LANG_C in the CTF loader.
Next csets will handle C++ in a different way, because we may need
to find class sizes in a different CU since ancestors sometimes
are only forward declared...
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Next we'll add a new kind of tag, DW_TAG_perf_counter, that will come
from perf.data generated by 'perf report'.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
That is used by cus__find_function_by_addr & cu__func_function_by_addr.
First user is pfunct --addr, but this is really for pfunct --annotate, that
will process a perf.data file generated by 'perf report', load the debugging
info and regenerate the functions (pfunct -TVi like) that had hits, using
libdisasm to show the assembly code, etc.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Sharing the same space with abstract_origin, so that we can remove the last
Dwarf_Off in dwarf_fprintf.c.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
There is still the problem of handing the strings table to the CTF encoder, but
that will be fixed another day.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
So that we can use the strings in ".strtab" directly, without duplicating them
on the global strings table.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Instead pass thru cu__strings(cu, i) so that we can figure out if the
underlying debugging format handler can do that more efficiently, such as by
looking up directly the ELF section ".strtab".
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Such as signed, etc. This is in preparation for using directly ctf_strings.
Instead of duplicating it in the global strings table.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
In the paste we ass-umed that if cu->dfops != NULL, all the methods would be
there, this ain't so anymore, so check it.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
That is done by adding some new struct debug_fmt_ops methods:
->function__name()
This one, if specified, will be called by function__name(), giving a chance to
formats such as CTF to get this from some other place than the global strings
table. CTF does this by storing GElf_Sym->st_name in function->name, and by
providing a dfops->function__name() that uses function->name as an index into
the .strtab ELF section.
->cu__delete()
This is needed because we can't anymore call ctf__delete at the end of
ctf__load_file, as we will need at least the .strstab ELF section to be
available till we're done with the cu, i.e. till we call cu__delete(), that now
calls dfops->cu__delete() if it is available.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
There are more things that should be handled differently, such as function
names coming from the .strtab ELF section instead of from the global strings_t
table.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
To cover the case where there aren't structs or even any type at all.
It looks now just like cu__for_each_function, so its more consistent as a bonus
:-)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Encoding all the non UNDEF OBJECT entries in the symtab. Some must be filtered
in upcoming patches, but for at least kernel/sched.o it works just fine.
To test it I used DaveM's ctfdump and also pdwtags on a --strip-debug, pahole
-Z CTF encoded object.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
For loaders to fill with the address of global variables.
More work is needed to cover relocation, registers, etc.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
We need it to be able to call cu__for_each_cached_symtab_entry more
than once in the same function.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Finally we can use the Elf file already opened in dwarf_load, call
cu__for_each_cached_symtab_entry to iterate over the symtab entries,
this iterator will first call dwfl_module_getsymtab, that will do the
relocation that will allow us to go from the symtab address to the one
in the DWARF DW_TAG_subprogram tag DW_AT_low_pc attribute.
And voila, for a relatively complex single unit Linux kernel object
file, kernel/sched.o, we go from:
Just DWARF (gcc -g):
$ ls -la kernel/sched.o
1979011 kernel/sched.o
Then we run this to encode the CTF section:
$ pahole -Z kernel/sched.o
And get a file with both DWARF and CTF ELF sections:
$ ls -la kernel/sched.o
2019848 kernel/sched.o
We still need to encode the "OBJECTS", i.e. variables, but this
gets us from 1979011 (just DWARF) to:
$ strip--strip-debug kernel/sched.o
$ ls -la kernel/sched.o
-rw-rw-r-- 1 acme acme 507008 2009-03-30 23:01 kernel/sched.o
25% of the original size.
Of course we don't have inline expansion information, parameter names,
goto labels, etc, but should be good enough for most use cases.
See, without DWARF data, if we ask for it to use DWARF, nothing will be
printed, if we don't speficy the format, it will try first DWARF, it
will not find anything, it will try CTF:
$ pahole -F dwarf kernel/sched.o
$ pahole -C seq_operations kernel/sched.o
struct seq_operations {
void * (*start)(struct seq_file *, loff_t *); /* 0 8 */
void (*stop)(struct seq_file *, void *); /* 8 8 */
void * (*next)(struct seq_file *, void *, loff_t *); /* 16 8 */
int (*show)(struct seq_file *, void *); /* 24 8 */
/* size: 32, cachelines: 1, members: 4 */
/* last cacheline: 32 bytes */
};
$ $ pfunct -Vi -f schedule kernel/sched.o
void schedule(void);
{ /* low_pc=0xe01 */
}/* size: 83 */
$
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
And also export the namespace destructor.
The tag__delete destructor now also uses these new destructors.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
CTF will need this distinction in that it handles functions differently, using
data in the ELF symbol table.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Because we already use ctf__load in libctf.c, rename the others to
disambiguate, and also as there are the __load_dir and __load_files
it looks more consistent.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
So after the next patch, when dwarf_loader will use this new core
functionality, it recognizes:
908 typedef int __m64 __attribute__ ((__vector_size__ (8))); size: 8
909 int array __attribute__ ((__vector_size__ (8))); size: 8
910 int array __attribute__ ((__vector_size__ (4))); size: 4
911 short int array __attribute__ ((__vector_size__ (2))); size: 2
912 char array __attribute__ ((__vector_size__ (1))); size: 1
The above output was obtained using pdwtags.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Nasty trick, but works and should be properly documented in the sources
and here:
If struct namespace.shared_tags is 1, we actually are reusing the list
of enumerators in another namespace, so we shouldn't delete them, for
that list_for_each_tag now means more for each _unshared_ tag, so that
cu__delete doesn't visits it, double freeing enumerator tags.
type__for_each_enumerator knows that and only for enums we'll set this
->shared_tags bit to 1, so we should be safe...
Disgusting? send me a patch, but without increasing memory or processing
footprints, please ;-)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
CTF doesn't have support for multiple array dimensions, so it flattens
the arrays.
This caused a large number of false positives in ctfdwdiff, so introduce
this conf_fprintf option, use it in pahole and ctfdwdiff.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
For a file with just DWARF info:
$ pahole -F ctf build/pahole
$
But if we ask that it also try dwarf:
$ pahole -F ctf,dwarf build/pahole | head -2
struct _IO_FILE {
int _flags; /* 0 4 */
$
Useful when testing the new CTF support in these tools, as we'll be able to,
from the DWARF info in objects, generate the CTF equivalent and add to the same
object, then run pahole -A -F ctf, pahole -A -F dwarf and compare the outputs.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
So that the user can specify what is the order it wants for decodind, as
we can have several debugging formats encoded in different ELF sections.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Will later be used when generating the CTF info, be it in a separate
file, be it on a new ELF section inserted into this filename.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
To shorten the name and to reflect the fact that we're no longer
"finding" a type, but merely accessing an array with a bounds check in
this function.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
We now create a new integral type (enum or base_types), creating typedef
chains if needed, while caching the bit_size and bit_offset, so that we
can easily reencode the whole file into CTF.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Needed for reencoding DWARF bitfields, where we need to create a new
enum that has a bitfield_size bits size.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
This will help us in the next csets when we need to know both the full
size of the base_type used in an bitfield _and_ the size in bits of the
bitfield member.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Because we will need the "bit_offset" and "bit_size" names when converting the
representation of offset and size everywhere to be in bits, not bytes.
At the same time we will keep bitfield_size and bitfield_offset when we convert
from DWARF to CTF and will calculate them when loading CTF, so that the
conversion of the algorithms in dwarves_reorganize, that have all sorts of
subtle issues, can be left for later.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
It makes no sense to try to lookup the abstract_origin (a Dwarf_Off)
after we recode the types just after load.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Amazing how many crept up over time, should have set the
execute bit of .git/hooks/pre-commit already, duh.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
So that we immensely reduce the memory footprint by doing filtering and
other processing/pretty printing as the cus are loaded, discarding them
right away.
The next cset will use this scheme in pahole.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Out of cu__find_struct_by_name so that we can do a string__find
once and lookup the string id on multiple cus.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Also introducing cus__load, that load just one file.
The new cus__load_files routine now iterates thru the provided array
calling cus__load for each, and that in turn will try first dwarf__load,
and if that fail, i.e. if no DWARF info is found, call ctf__load.
This now allows loading DWARF _and_ CTF files at the same time. This
will be useful in the future when we, from DWARF generate CTF and at the
same time do a codiff, comparing the freshly generated CTF file with the
DWARF it came from.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Not used anymore now that cus__loadfl is sanitized. Now we can even
remove the fl (historically comes from libdwfl, when we used to pass an
argp, argh!).
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
So that, when not needing the DWARF info, the apps can tell that at load
time, and then the dwarf loader can just free all the dwarf_tags
allocated, reducing memory usage.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
To visit all parms, lexblocks, namespaces, i.e. not just the top level
tags listed in cu->tags.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
To take advantage of cache effects and to avoid calling cu__find_holes
more than once on the same struct.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>