http://blog.gmane.org/gmane.comp.debugging.dwarves hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.debugging.dwarves/82 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 > Diego 'Flameeyes' Pettenò 2008-06-14T09:43:44 http://comments.gmane.org/gmane.comp.debugging.dwarves/80 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ò 2008-05-21T12:04:26 http://comments.gmane.org/gmane.comp.debugging.dwarves/77 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ò 2008-05-01T00:22:38 http://comments.gmane.org/gmane.comp.debugging.dwarves/71 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__ Dave Rigby 2008-04-21T14:22:14 http://comments.gmane.org/gmane.comp.debugging.dwarves/67 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 Florin Iucha 2008-03-25T15:24:03 http://comments.gmane.org/gmane.comp.debugging.dwarves/62 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ò 2008-03-12T11:29:34 http://comments.gmane.org/gmane.comp.debugging.dwarves/57 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ò 2008-02-15T12:54:22 http://comments.gmane.org/gmane.comp.debugging.dwarves/49 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 Arnaldo Carvalho de Melo 2008-02-12T00:03:10 http://comments.gmane.org/gmane.comp.debugging.dwarves/48 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 <hagen-GvnIQ6b/HdU< at >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) Hagen Paul Pfeifer 2008-02-10T20:52:15 http://comments.gmane.org/gmane.comp.debugging.dwarves/47 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. Diego 'Flameeyes' Pettenò 2008-02-10T19:23:34 http://comments.gmane.org/gmane.comp.debugging.dwarves/46 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). Felipe Kellermann 2008-01-31T22:34:40 http://comments.gmane.org/gmane.comp.debugging.dwarves/43 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 Erik Ekman 2008-01-28T15:31:55 http://comments.gmane.org/gmane.comp.debugging.dwarves/18 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 (ol jamal 2008-01-10T12:42:48 http://comments.gmane.org/gmane.comp.debugging.dwarves/1 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/pahol Hagen Paul Pfeifer 2007-12-24T22:41:57 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.debugging.dwarves