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>
Too DWARF specific and wasn't working since I implemented type recoding and
removed the Dwarf_Off from struct tag.
To achieve the same result one can use --show_decl_info that also shows the
dwarf offset, since it needs to keep the DWARF specific line number and file
and then use a text editor to find the offset.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Moving more CTF only stuff out of the dwarves land and into something that can
be more easily stolen by other projects not interested in funny named stuff
such as pahole.
This also will help with encoding, as we will normally be recoding data from
DWARF, so the ELF file will be available and we will just add a new section to
it.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The ctf_loader.c file should be a direct counterpart to dwarf_loader,
that is, it should have just use what is in libctf to decode the CTF
sections and convert it to the core format in dwarves.[ch].
Also introduce a ctf__string32 for the very common idiom:
ctf_string(ctf__get32(sp->ctf, &tp->base.ctf_name), sp);
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
We will need this when encoding the CTF functions section. Things like lookup
a function by its address when converting from a DW_TAG_subprogram to a CTF
function, for instance.
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>
So now 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>
With this a "make allyesconfig" on a 2.6.29-rc8 Linux kernel build left 16
cases flagged by ctfdwdiff, 8 unique ones, out of 6209 single-cu (compile unit)
.o files.
But what this clearly shows is that we really need to detect if a struct is
packed, and wether it is naturally packed or if __attribute__ packed was used,
that way we will have more clues as to if a enum is packed or if the whole
struct where it is used as a type for a/several member(s) is packed.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
As we will show them on the first level. This is yet another thing
required to properly compare te result of "pahole -F ctf foo" with the
output of "pahole -F dwarf foo", as there is no support, that I know of,
for namespacing in ctf.
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>
At least in our encoder, as we support enum bitfields, so if it comes
zeroed, as in the other implementation, we assume 8 * sizeof(int), if
not, its the bitsize.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
By default pahole doesn't prints structs/classes that are only defined
inside functions, so add a knob to aks for that.
This is for the benefit of ctfdwdiff, as in CTF we don't have
expressiveness to tell that a struct is only defined inside a function,
its all in the global table.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Just like free, and as this is the common exit path of the tools, we
better do that not to segfault when not asking for something. ;-)
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>
So that I can run it with:
find . -type d | while read dir ; do cd $dir ; ls *.o 2> /dev/null |
while read file ; do ctfdwdiff $file ; done ; cd - ; done
for instance.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
First it gets a file with DWARF info, converts that to CTF and adds
a ".SUNW_ctf" ELF section to the file with DWARF info. Double debugging
foo! Pay for one, take two!
For tcp_input.o for instance, the result is:
[acme@doppio pahole]$ cat /tmp/tcp_input.o.diff
--- /tmp/tcp_input.o.ctf.c 2009-03-19 19:48:23.000000000 -0300
+++ /tmp/tcp_input.o.dwarf.c 2009-03-19 19:48:23.000000000 -0300
@@ -1811,7 +1811,7 @@
/* XXX 6 bytes hole, try to pack */
- void (*call)(const struct marker *, void *); /* 24 8 */
+ void (*call)(const struct marker *, void *, ...); /* 24 8 */
struct marker_probe_closure single; /* 32 16 */
struct marker_probe_closure * multi; /* 48 8 */
const char * tp_name; /* 56 8 */
[acme@doppio pahole]$
Now back to figuring out how to encode a VARARGS marker in CTF...
Ah, to use the script just do:
./ctfdwdiff foo.o
Some will crash, but we're working hard for fuller customer
satisfaction.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
And use what worked so far, that is: if the section is already there,
replacing its contents works, because probably all the relocation was
done... If not, be a chicken and call system("objcopy..."), but...
I'llll be bahck!
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
And make the output go to stderr.
I guess the best we can do about these is to completely ignore them,
well see...
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>
"pahole -Z foo" will create foo.SUNW_ctf, that if objcopy
--add-section'ed to the right word-sized object will work, sans VARARGS,
that will get fixed soon (as in, probably, tomorrow).
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>
Arnaldo Carvalho de Melo