The changeset:
commit f043528
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date: Sun Aug 16 12:26:33 2009 -0300
dwarves_reorganize: Fix class__demote_bitfields, we need power of
two bytes
Had a correct changeset description, but an incorrect implementation, it
was not rouding up to the next power of two, but to the next multiple of
2, i.e. when a bitfield has 2 bits, it was deciding it needed 2 bytes,
not 1.
Fix it by copying the roundup_power_of_two code from the Linux kernel,
mostly by David Howells <dhowells@redhat.com>.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
When computing the size of a class, leave, caused problems in
some cases, links to the reports are in the comments.
Reported-by: Nicolas <nikos42@gmail.com>
Suggested-by: Mark Wielaard <mjw@redhat.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
As Thomas Gleixner wisely pointed out, using 'self' is stupid, it
doesn't convey useful information, so use sensible names.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
After emitting a warning that a tag is not supported __die__process_tag
was returning NULL, making die__process_unit think that the problem
was insufficient memory.
Introduce a global variable 'unsupported_tag' and return it instead,
that way die__process_unit can distinguish ENOMEM from unsupported tags.
Reported-by: Thiago Macieira <thiago.macieira@intel.com>
Tested-by: Thiago Macieira <thiago.macieira@intel.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The 2938a70 changeset incorectly changed some searches that needed to be
done on the all tags hashtable to the type only one.
This lead to problems such as:
[acme@sandy pahole]$ build/pahole /usr/lib/debug/usr/libexec/pt_chown.debug > /dev/null
tag__recode_dwarf_type: couldn't find 0xf7a type for 0x1133 (inlined_subroutine)!
tag__recode_dwarf_type: couldn't find 0x1047 type for 0x1166 (inlined_subroutine)!
tag__recode_dwarf_type: couldn't find 0xf7a type for 0x11a8 (inlined_subroutine)!
lexblock__recode_dwarf_types: couldn't find 0xf7a type for 0x1133 (inlined_subroutine)!
lexblock__recode_dwarf_types: couldn't find 0x1047 type for 0x1166 (inlined_subroutine)!
lexblock__recode_dwarf_types: couldn't find 0xf7a type for 0x11a8 (inlined_subroutine)!
[acme@sandy pahole]$
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'.
Before this patch, running pahole on an executable compiled
with -gdwarf-4 gave:
DW_AT_<0x3c>=0x19
0x19 is DW_FORM_flag_present.
Also, DW_FORM_flag takes an argument.
Changing attr_numeric to call dwarf_formflag fixes both problems.
RHEL5 and Fedora 11 were not building due to the GNU attributes stuff,
cope with that using a define we know is not present in both RHEL5 and
Fedora 11 to #ifdef those parts. Ugly, but _ELFUTILS_PREREQ, i.e.
elfutils/version.h is not present in RHEL5 either.
Reported-by: Jon Stanley <jstanley@fedoraproject.org>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
More work is needed to use this information in dwarves_fprintf.c.
Reported-by: Josh Stone <jistone@redhat.com>
Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=654471
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Needed because it uses S_ISDIR. In the past this header probably was
being indirectly included. Noticed while building on RHEL6 Beta.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
To print all the function prototypes.
Based-on-patch-by: Rakesh Pandit <rakesh.pandit@gmail.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
- "-s section 0" doesn't really read the same as "-s section0"
- "--help" is something we should allow
- usage should say "scncopy" not "pjoc"
Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
This adds scncopy, which is like objcopy with some differences:
- it doesn't try to update section contents, but does try to
update program headers and such to correctly reflect the section
contents.
- it doesn't necessarily try to create a binary eu-elflint will like.
If you don't copy a required section, it won't make it for you.
TODO:
- Make it possible to copy sections to an already existant binary.
- Make phdrs only copy if they're needed, and/or modify old phdrs to
point to new sections
- Make sure nothing is missing from fixup_dynamic()
Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
currently mandriva has a packaging script which checks for uneeded linking in
package built files. For dwarves, it displays:
Warning: unused libraries in /usr/lib64/libdwarves_reorganize.so.1.0.0: libdw.so.1
libelf.so.1
libz.so.1
Warning: unused libraries in /usr/lib64/libdwarves_emit.so.1.0.0: libdw.so.1
libelf.so.1
libz.so.1
Warning: unused libraries in /usr/bin/ctracer: libz.so.1
libdw.so.1
Warning: unused libraries in /usr/bin/syscse: libdw.so.1
libelf.so.1
libz.so.1
Warning: unused libraries in /usr/bin/pglobal: libdw.so.1
libelf.so.1
libz.so.1
Warning: unused libraries in /usr/bin/pdwtags: libdw.so.1
libelf.so.1
libz.so.1
Warning: unused libraries in /usr/bin/prefcnt: libdw.so.1
libelf.so.1
libz.so.1
Warning: unused libraries in /usr/bin/pfunct: libz.so.1
libdw.so.1
Warning: unused libraries in /usr/bin/pahole: libz.so.1
libdw.so.1
libelf.so.1
Warning: unused libraries in /usr/bin/dtagnames: libdw.so.1
libelf.so.1
libz.so.1
Warning: unused libraries in /usr/bin/codiff: libdw.so.1
libelf.so.1
libz.so.1
The patch below fixes the issue (removing uneeded specified libraries and using
LINK_INTERFACE_LIBRARIES property, see
http://www.cmake.org/Wiki/CMake_FAQ#Why_are_libraries_linked_to_my_shared_library_included_when_something_links_to_it.3F)
Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
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>