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>
Description by Mark Wielaard:
Its a more compact expression of struct field offsets. Jakub already
backported it to the 4.4 gcc in rawhide.
http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00437.html It simply means
that when you try to get the field offset based on a
DW_AT_data_member_location you would check dwarf_whatform() of the
attribute to see if it is a simple constant or a location expression
block/ptr.
Suggested-by: Mark Wielaard <mjw@redhat.com>
Reported-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
When dwarf_lowpc failed we were not initializing ->size, so garbage was
being left there and thing like 'pfunct --sizes' were producing
senseless results.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
As it is corrupting the obstack and it will be deleted completely at
cu__delete time anyway. Stick a FIXME tho, as it is good to completely
understand and fix this eventually.
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>
C++ is not properly supported in CTF anyway... And this was
causing a bug, so don't encode DW_TAG_inheritance entries.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
I.e.:
[acme@doppio pahole]$ cat tests/jengelh@medozas.de/const_const.c
struct x {
const char *const s;
} y;
int main(void)
{
return !y.s;
}
[acme@doppio pahole]$ pahole tests/jengelh@medozas.de/const_const
struct x {
char const * const s; /* 0 8 */
/* size: 8, cachelines: 1, members: 1 */
/* last cacheline: 8 bytes */
};
[acme@doppio pahole]$
One more reason to devote some time to RTT, i.e. Round Trip Testing, where
pahole will be used to regenerate the source code, then feed the result to
gcc -g, run again, use codiff, that should produce no diff.
Reported-by: Jan Engelhardt <jengelh@medozas.de>
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>
For now --encode_ctf/-Z only encodes the tags in the first object file
(CU) in a multi-obj/CU file, so for regtest sake, for now, introduce
this option.
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>
To encode CTF information from the DWARF one. Next patches will add
support for comparing the CTF and DWARF info.
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>
I'm using it using a directory with all debuginfo packages in fedora, so
that I can run a before and after with different tools (pahole, pfunct),
and check the differences after some change.
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>
We can't always pad using the module of addr_size, we need to find the
minimum alignment requirement as a power of two < addr_size.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Where we end up with the same struct but class__size() returns off by
some bytes result. Investigating...
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
When we move fields from the tail to eliminate holes look if the struct
still correctly fits into a multiple of cu->addr_size.
Unless the struct is explicitely marked __attribute__((packed)) (and we
can't know that for sure) we have to add padding in that case.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Arnaldo Carvalho de Melo