In the past we did integer testing, and testing against 0 was no problem, but
now they return NULL and we are back using strcmp, oops.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
So that we can more early return if we can't process files for some supported
debugging format and as well release all resources allocated when dwarves__exit
is called.
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>
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>
ctracer was segfaulting due to this problem.
Reported-by: Breno Leitão <leitao@linux.vnet.ibm.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
And not compare by string_t, as now it may not be on the global strings table,
so we have to give a chance to the underlying debug format to translate that to
a string for us.
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>
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>
Only seen in some C++ inline expansion cases. Will appear as "(null)" in the
rendered source code.
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>
I have to normalize this so that we don't have this special case, but
since we can have enum bitfields....
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>
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>
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>
Arnaldo Carvalho de Melo