headers
Arnaldo Carvalho de Melo | 4 Jul 22:00

pahole --contains explained

Em Fri, Jul 04, 2008 at 09:54:12AM +0200, Dennis Lubert escreveu:
> Am Donnerstag, den 03.07.2008, 14:08 -0300 schrieb Arnaldo Carvalho de Melo:
> > > - There could be some glob or regexp style substring match for types.
> > > >From the --help I thought that -i was for this, but I could not get it
> > > to match even on substrings... Am I maybe doing something wrong?

> > Regexps not supported yet, just prefixes:

> > [acme <at> doppio pahole]$ pahole --sizes --separator=, build/pahole | grep arg
> > argp_child,32,1
> > argp,56,0
> > argp_state,96,1
> > argp_option,48,2
> > [acme <at> doppio pahole]$ pahole --sizes --separator=, --exclude arg build/pahole | grep arg
> > [acme <at> doppio pahole]$

> Ah ok, just overlooked -y/-x ... but then I am a bit confused on what -i
> means. Giving it parts of the class, prefixes or even the whole name
> leads to no result here... 

-i == --contains

[acme <at> doppio pahole]$ pahole -i tag build/pahole 
parameter
ftype
lexblock
class_member
array_type
base_type
namespace
(Continue reading)

Permalink | Reply | 0 comments |
headers
Diego 'Flameeyes' Pettenò | 14 Jun 11:40

Errors during a pfunct scan for amarokcollectionscanner and inkscape


Hi :)

On http://www.flameeyes.eu/tmp/dwarves-again.tbz2 you can find the
executables amarokcollectionscanner and inkscape from my workstation
(Gentoo Linux AMD64), they report these errors when scaning them with
pfunct:

flame <at> enterprise ~ % pfunct /usr/bin/amarokcollectionscanner
dwarf_expr: unhandled 0x12 DW_OP_ operation
dwarf_expr: unhandled 0x12 DW_OP_ operation

as for inkscape:

die__create_new_subroutine_type: DW_TAG_typedef @ <0x6efd> not handled!
die__create_new_subroutine_type: DW_TAG_typedef @ <0x27f5c> not handled!
die__create_new_subroutine_type: DW_TAG_typedef @ <0x5c595> not handled!
die__create_new_subroutine_type: DW_TAG_typedef @ <0x6ff53> not handled!
die__create_new_subroutine_type: DW_TAG_typedef @ <0x72aa8> not handled!
die__create_new_subroutine_type: DW_TAG_typedef @ <0x9b03c> not handled!
die__create_new_subroutine_type: DW_TAG_typedef @ <0xb1ed8> not handled!
die__create_new_subroutine_type: DW_TAG_typedef @ <0xbd92a> not handled!
die__create_new_subroutine_type: DW_TAG_typedef @ <0xc2695> not handled!
die__create_new_subroutine_type: DW_TAG_typedef @ <0xc8a1d> not handled!
die__create_new_subroutine_type: DW_TAG_typedef @ <0xe6963> not handled!
die__create_new_subroutine_type: DW_TAG_typedef @ <0x102f92> not handled!
die__create_new_subroutine_type: DW_TAG_typedef @ <0x10aea1> not handled!
die__create_new_subroutine_type: DW_TAG_typedef @ <0x10f886> not handled!
die__create_new_subroutine_type: DW_TAG_typedef @ <0x11c1a9> not handled!
die__create_new_subroutine_type: DW_TAG_typedef @ <0x129f32> not handled!
(Continue reading)

Permalink | Reply | 3 comments |
headers
Diego 'Flameeyes' Pettenò | 21 May 14:01

Another strange codiff output


While cleaning up xine-lib's code I found another interesting thing:

send_ogg_buf         |  +24 # 3671 -> 3695, # inlines: 0 -> 1, size inlines: 0 -> 859
send_header          | -116 # 7812 -> 7696, # inlines: 13 -> 1, size inlines: 6765 -> 418

I'm not sure if this is correct, but if the size of inlines increases so
much and decreases so much, I'd expect the size of the function to
follow suit..

The ELF files causing this are at
http://www.flameeyes.eu/tmp/dwarves-notsure.tbz2 .

HTH,
--

-- 
Diego "Flameeyes" Pettenò
http://blog.flameeyes.eu/
Permalink | Reply | 1 comment |
headers
Arnaldo Carvalho de Melo | 12 May 19:54

Re: The strange ever-changing structure :)

CCing dwarves ML

Em Mon, May 12, 2008 at 07:29:17PM +0200, Diego 'Flameeyes' Pettenò escreveu:
> http://www.flameeyes.eu/tmp/dwarves-strange.tbz2
> 
> The rest of the differences are correct, I'm doing some micro-optimisation to 
> the code, but this:
> 
> ../../../src/xine-engine/alphablend.c:
>   struct header_s |  -24
>     data
>      from: uint8_t *             /*     8(0)    48(0) */
>      to:   uint8_t *             /*     8(0)    24(0) */
>  1 struct changed
> 
> 
> I always find in my codiff outputs...

Using readelf we can see that we have two header_s definitions:

One that is local to the blend_yuy2_grow_extra_data function and has 32
bytes:

 <2><5d2b2>: Abbrev Number: 19 (DW_TAG_structure_type)
    <5d2b3>   DW_AT_name        : (indirect string, offset: 0x79c6): header_s   
    <5d2b7>   DW_AT_byte_size   : 32    
    <5d2b8>   DW_AT_decl_file   : 1     
    <5d2b9>   DW_AT_decl_line   : 1549  
    <5d2bb>   DW_AT_sibling     : <0x5d2ec>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Diego 'Flameeyes' Pettenò | 1 May 02:21

Unknown error 18446744073709551615


I'm not sure what is causing this, but while trying to compare two
different versions of openrc's rc binary I got this error. I'm running
dwarves from Git of a day or two ago.

The two files are in http://www.flameeyes.eu/tmp/dwarves-error.tbz2

--

-- 
Diego "Flameeyes" Pettenò
http://blog.flameeyes.eu/
Permalink | Reply | 1 comment |
headers
Dave Rigby | 21 Apr 16:21

[PATCH] Add support for filtering classes based on name

i,

While pahole allows you to exclude classes with a specified prefix (using
--exclude), it doesn't appear to be able to do the opposite - only show
classes with a specific prefix. I found I needed this for my own use of it,
so here is a patch to add this functionality. It seems like it could be
useful for others:

Thanks

Dave Rigby

diff --git a/pahole.c b/pahole.c
index 7053471..e16ac2d 100644
--- a/pahole.c
+++ b/pahole.c
@@ -26,6 +26,9 @@ static uint8_t word_size, original_word_size;
 static char *class__exclude_prefix;
 static size_t class__exclude_prefix_len;

+static char *class__include_prefix;
+static size_t class__include_prefix_len;
+
 static char *cu__exclude_prefix;
 static size_t cu__exclude_prefix_len;

@@ -350,6 +353,20 @@ static struct tag *tag__filter(struct tag *tag, 
struct cu *cu,
 			return NULL;
 	}
(Continue reading)

Permalink | Reply | 3 comments |
headers
Florin Iucha | 25 Mar 16:23

"File has no CTF section."

I have manually built the pahole&co on Ubuntu 8.04 beta, and I'm
trying to use it on a few source files that I have, and I keep getting
the "File has no CTF section." error message.

I have three object files: one is 'dwarves.o' from the pahole
distribution, compiled with 'gcc -g'.  Another is 'foobar.o' from my
own embedded application, compiled with the same compiler, on the same
box [1].  The third object file is 'foobar.o' compiled with some
version of compiler (Metrowerks?) for the embedded platform that we use.

If I use 'objdump -W' on all three files, I get heaps of information,
including the structure definitions and other stuff.  Good.

If I use 'pahole' on all three files, I get the structure information
for the first one, but 'File has no CTF section.' for the other two,
even though the first and second object files are built with the same
compiler!  And even though both 'foobar.o' file contain heaps of
debugging information (objdump -W yields 14K lines for the gcc-4.2
build and 43K lines for the native embedded build).

I grepped for 'File has no CTF section.' in the dwarves sources and it
only occurs in the 'ctf_loader.c' file - it seems that the code is
looking for a section named ".SUNW_ctf" (in function parse_elf which
is only called from ctf__load which is only called from cus__loadfl,
if the dwarf__load returns some empty list)

It seems that either 'dwfl_getdwarf/dwarf_nextcu' fails to find the
data.  At any rate, the error message (about the missing CTF section)
is quite misleading.  I'm not sure where the bug is (although my
limited exploring seems to point to the 'elfutils' package.  Ubuntu
(Continue reading)

Permalink | Reply | 5 comments |
headers
Arnaldo Carvalho de Melo | 20 Mar 21:51

Re: building pahole on Ubuntu 8.04 AMD64

Em Thu, Mar 20, 2008 at 03:02:44PM -0500, Florin Iucha escreveu:
> Hi Arnaldo,
> 
> I'm trying to build the pahole tools on Ubuntu 8.04 AMD64 and I'm
> getting a build error:
> 
> $ make
> [  5%] Building C object CMakeFiles/dwarves.dir/dwarves.o
> [ 11%] Building C object CMakeFiles/dwarves.dir/ctf_loader.o
> [ 17%] Building C object CMakeFiles/dwarves.dir/libctf.o
> [ 23%] Building C object CMakeFiles/dwarves.dir/dwarf_loader.o
> Linking C shared library libdwarves.so
> /usr/bin/ld:
> /usr/lib/gcc/x86_64-linux-gnu/4.2.3/../../../../lib64/libdw.a(dwarf_begin.o):
> relocation R_X86_64_32 against `a local symbol' can not be used when
> making a shared object; recompile with -fPIC
> /usr/lib/gcc/x86_64-linux-gnu/4.2.3/../../../../lib64/libdw.a: could
> not read symbols: Bad value
> collect2: ld returned 1 exit status
> make[2]: *** [libdwarves.so.1.0.0] Error 1
> make[1]: *** [CMakeFiles/dwarves.dir/all] Error 2
> make: *** [all] Error 2
> 
> I grepped for -fPIC and it seems to be passed on the command line for
> many of the sources.  I'm using libdw-dev version 0.131-3 and binutils
> 2.18.1~cvs20080103-0uubuntu1 as packaged by Ubuntu.

Strange, looks like you have libdw-dev 32bits installed? can you check
that? I.e. that cmake is not mixing somehow libraries?
(Continue reading)

Permalink | Reply | 2 comments |
headers
Diego 'Flameeyes' Pettenò | 12 Mar 12:26

Little request: a notice of new releases :)


Hi there,

just having a liiitle request, could you pleas send an email when you
release a new version of dwarves? It makes it easier to maintain it in
Gentoo if I know a new release is made :)

And until I can get specto to work or find something similar, polling
the tarballs page is boring ...

--

-- 
Diego "Flameeyes" Pettenò
http://blog.flameeyes.eu/
Permalink | Reply | 1 comment |
headers
Diego 'Flameeyes' Pettenò | 15 Feb 13:52

dwarf_expr: unhandled 0x12 DW_OP_ operation


I'm trying to use pfunct to identify software that bundles internal
copies of common libraries (I've started with zlib's adler32 function
for now), and I've seen this message being repeated tons of times for
kile, kxmleditor, VirtualBox and a lot more stuff.

Has anybody an idea of what that means?

Thanks,
--

-- 
Diego "Flameeyes" Pettenò
http://farragut.flameeyes.is-a-geek.org/
Permalink | Reply | 4 comments |
headers
Arnaldo Carvalho de Melo | 12 Feb 01:02

speedup in tag lookup using hash tables

Hi Ilpo,

	Today I optimized the dwarves a bit by using a per object file
hash table for tag lookup, it yelded almost 50% speedup on pahole when
running on a vmlinux file :-)

	codiff doesn't makes that much tag lookups, so we didn't got
much improvements there, but I'm doing experiments on dead tag elimination
that probably will help a lot there, but for that I have first to grok
Ulrich Drepper's libdisasm to find out what are the tags that are really
used by looking at accesses to register indexed memory areas that use as
a base pointer what is in local/global variables and function
parameters.

	This also will provide the basis for detecting access patterns
that will ultimatelly allow libdwarves_reorganize to do struct
reorganizations to improve locality of reference, etc.

	Please take a look at v1.6 that I pushed today and tell me your
impressions.

Regards,

- Arnaldo
Permalink | Reply | 3 comments |

Gmane