gmane.comp.debugging.dwarves

Errors during a pfunct scan for amarokcollectionscanner and inkscape

Diego 'Flameeyes' Pettenò — 2008-06-14T09:43:44

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 < at > <0x6efd> not handled! die__create_new_subroutine_type: DW_TAG_typedef < at > <0x27f5c> not handled! die__create_new_subroutine_type: DW_TAG_typedef < at > <0x5c595> not handled! die__create_new_subroutine_type: DW_TAG_typedef < at > <0x6ff53> not handled! die__create_new_subroutine_type: DW_TAG_typedef < at > <0x72aa8> not handled! die__create_new_subroutine_type: DW_TAG_typedef < at > <0x9b03c> not handled! die__create_new_subroutine_type: DW_TAG_typedef < at > <0xb1ed8> not handled! die__create_new_subroutine_type: DW_TAG_typedef < at > <0xbd92a> not handled! die__create_new_subroutine_type: DW_TAG_typedef < at > <0xc2695> not handled! die__create_new_subroutine_type: DW_TAG_typedef < at > <0xc8a1d> not handled! die__create_new_subroutine_type: DW_TAG_typedef < at > <0xe6963> not handled! die__create_new_subroutine_type: DW_TAG_typedef < at > <0x102f92> not handled! die__create_new_subroutine_type: DW_TAG_typedef < at > <0x10aea1> not handled! die__create_new_subroutine_type: DW_TAG_typedef < at > <0x10f886> not handled! die__create_new_subroutine_type: DW_TAG_typedef < at > <0x11c1a9> not handled! die__create_new_subroutine_type: DW_TAG_typedef < at > <0x129f32> not handled! die__create_new_subroutine_type: DW_TAG_typedef < at > <0x14aa06> not handled! dwarf_expr: unhandled 0x12 DW_OP_ operation and it continues for a long time. This is dwarves from GIT of a few days ago. HTH,

Another strange codiff output

Diego 'Flameeyes' Pettenò — 2008-05-21T12:04:26

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,

Unknown error 18446744073709551615

Diego 'Flameeyes' Pettenò — 2008-05-01T00:22:38

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

[PATCH] Add support for filtering classes based on name

Dave Rigby — 2008-04-21T14:22:14

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 < at >< at > -26,6 +26,9 < at >< at > 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; < at >< at > -350,6 +353,20 < at >< at > static struct tag *tag__filter(struct tag *tag, struct cu *cu, return NULL; } +if (class__include_prefix != NULL) { +if (name == NULL) { +const struct tag *tdef = +cu__find_first_typedef_of_type(cu, tag->id); +if (tdef != NULL) +name = class__name(tag__class(tdef), cu); +} + +if (name != NULL && strncmp(class__include_prefix, name, + class__include_prefix_len) != 0) +return NULL; +} + + if (decl_exclude_prefix != NULL && (tag->decl_file == NULL || strncmp(decl_exclude_prefix, tag->decl_file, < at >< at > -820,6 +837,12 < at >< at > static const struct argp_option pahole__options[] = { .doc = "exclude PREFIXed classes", }, { +.name = "prefix_filter", +.key = 'y', +.arg = "PREFIX", +.doc = "include PREFIXed classes", +}, +{ .name = "cu_exclude", .key = 'X', .arg = "PREFIX", < at >< at > -910,6 +933,9 < at >< at > static error_t pahole__options_parser(int key, char *arg, case 'x': class__exclude_prefix = arg; class__exclude_prefix_len = strlen(class__exclude_prefix); break; + case 'y': class__include_prefix = arg; + class__include_prefix_len = strlen(class__include_prefix); + break; case 'z': hole_size_ge = atoi(arg); if (!global_verbose) -- To unsubscribe from this list: send the line "unsubscribe dwarves" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html

"File has no CTF section."

Florin Iucha — 2008-03-25T15:24:03

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 distributes version 0.131, which seems to be the latest published version. The most puzzling thing is that two object files, compiled with the same compiler on the same machine have different enough DWARF data that one works with pahole and one doesn't. What can I do to follow through with this? Contact the elfutils maintainers? Thanks, florin 1: The compiler version is 'gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu6)'

Little request: a notice of new releases :)

Diego 'Flameeyes' Pettenò — 2008-03-12T11:29:34

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 ...

dwarf_expr: unhandled 0x12 DW_OP_ operation

Diego 'Flameeyes' Pettenò — 2008-02-15T12:54:22

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,

speedup in tag lookup using hash tables

Arnaldo Carvalho de Melo — 2008-02-12T00:03:10

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

[PATCH 1/1] define memdup() static

Hagen Paul Pfeifer — 2008-02-10T20:52:15

memdup() is only referenced from dwarves.c. This patch defines them static. Further symbol hiding can be accomplished via GCC attributes: #if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 4) # define DWARVES_NO_EXPORT __attribute__((visibility("hidden"))) #else # define DWARVES_NO_EXPORT #endif Signed-off-by: Hagen Paul Pfeifer public.gmane.org> --- dwarves.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/dwarves.c b/dwarves.c index 813c67b..aa9510e 100644 --- a/dwarves.c +++ b/dwarves.c < at >< at > -114,7 +114,7 < at >< at > static void *zalloc(const size_t size) return s; } -void *memdup(const void *src, size_t len) +static void *memdup(const void *src, size_t len) { void *s = malloc(len); if (s != NULL)

libdwarves exports a generic memdup() symbol

Diego 'Flameeyes' Pettenò — 2008-02-10T19:23:34

And for what it's worth, it's not used by the dwarves tools. It's actually in good company: Symbol memdup< at >< at > (64-bit UNIX System V ABI AMD x86-64 architecture) present 7 times /usr/lib64/libnetsnmp.so.15.1.0 /lib64/security/pam_smbpass.so /usr/lib64/samba/libmsrpc.so /usr/lib64/libsnmp.so.15.1.0 /usr/lib64/libdwarves.so.1.0.0 /usr/lib64/samba/security/pam_smbpass.so /usr/lib64/samba/libsmbclient.so It should probably be hidden anyway.

[PATCH] Fixes a FIXME relating to a missing elf (libdw) symbol check.

Felipe Kellermann — 2008-01-31T22:34:40

Hello, I was trying to build pahole using git HEAD using the latest Ubuntu (7.10) and noticied that there is a missing check of a symbol and a FIXME tag pointing that. The attached patch adds a cmake configure (config.h) file and checks the symbol (dwfl_module_build_id).

Creating ELF function/file size statistics

Erik Ekman — 2008-01-28T15:31:55

Hi I am doing some developing in C and want to see ELF size per function, file and directory. Right now I extract the sizes of functions and fields from objdump and use an ugly sed hack to find the file of each function/object, and then a python script that does some matching. I read about the DWARF format and it seems it includes the things I need. The output from objdump -W and eu-readelf -w shows that functions and object are tied to a file in some way. Does any of the existing dwarf programs do this? pdwtags looked as a best fit from reading the OLS paper. I have not fetched the latest source yet due to some workplace firewalls. If no tool does this and it is possible, then I am interested in developing one. Please cc me, i am not on the list. /Erik

eat your own dog food?

jamal — 2008-01-10T12:42:48

Hey Arnaldo, You ever tasted what you are cooking?;-> --- hadi< at >lilsol:~/git-trees/arnaldo/jamal/build$ pahole ./pahole| grep XXX /* XXX last struct has 1 byte of padding */ /* XXX 1 bit hole, try to pack */ /* XXX 1 byte hole, try to pack */ /* XXX 2 bytes hole, try to pack */ /* XXX 2 bits hole, try to pack */ /* XXX 1 byte hole, try to pack */ /* XXX last struct has 2 bytes of padding */ /* XXX 1 byte hole, try to pack */ hadi< at >lilsol:~/git-trees/arnaldo/jamal/build$ --- On a serious note, feature request: I am trying to put words to what i am looking for and it's a little hard without providing a lot of boring context. For brevity, lets say i have an inherited 500K lines of code. Assume i compiled a program for 32-bit target and now i have to move it to a 128-bit playstation 3 with whatever strange alignment rules. I want to do achieve 2 and a half things: a) i) check the structure for holes for X-bit access alignment where X is 16 (old 680xx), 64, 128. I want to do this without compiling the program for any of those targets i.e i want to do this on my x86 32-bit laptop ;-> i.e call this cross-pahole ii) If i can do the above; i should then be able to say "optimize" (what you call --reorganize) for X-bit b) I want to do a multiple of these example "optimize for 32-bit and 64-bit" or "check if it is safe for 128-bit and 16-bit alignemnt" Note, clearly if i can make it read config files with rules for something like the MIPS EABI in the first part of this email: http://sourceware.org/ml/binutils/2003-06/msg00436.html then i can say "check if it safe for mips 32 bit and x86_64" ;-> And i can make sure my apps will run on that new cpu i dont have access to. I could ask for more, but let me start/stop here incase you are going to lynch me;-> cheers, jamal - To unsubscribe from this list: send the line "unsubscribe dwarves" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html

new pahole packet structure

Hagen Paul Pfeifer — 2007-12-24T22:41:57

First one! ;-) I re-structured the packet layout, droped cmake support with a lightweight ./configure replacement and fix some new occurred compiler warnings. Hello Arnaldo, I replaced the current build system with a more common configure && make && make install tuple. I drooped the cmake dependencies completely - now a hand-crafted configure script replace the functionality. There are some tiny issues for further releases: e.g. check for a valid elfutils package (version > elfutils-0.128), sqlite checks, etc. The current version doesn't utilize any auto-helltools, but the fundamental structure is prepared. So if there is a demand in the future: no problem! ;) I doesn't touched any functionality - no code is altered (expect some compiler warnings, due to additional compiler flags. But there are some additional warnings!). The whole tarball is a packed git archive (master branch). The last commit was b4d6de9b6f6. You can pull (and merge) it therefore locally. ;) http://jauu.net/var/misc/exchange/pahole-new.tar.bz2 Hagen