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>