gmane.comp.debugging.dwarves

pahole --contains explained

Arnaldo Carvalho de Melo — 2008-07-04T20:00:16

Em Fri, Jul 04, 2008 at 09:54:12AM +0200, Dennis Lubert escreveu: -i == --contains [acme< at >doppio pahole]$ pahole -i tag build/pahole parameter ftype lexblock class_member array_type base_type namespace [acme< at >doppio pahole]$ Now lets look at some of these classes: [acme< at >doppio pahole]$ pahole -C ftype build/pahole struct ftype { struct tag tag; /* 0 64 */ /* --- cacheline 1 boundary (64 bytes) --- */ struct list_head parms; /* 64 16 */ uint16_t nr_parms; /* 80 2 */ uint8_t unspec_parms; /* 82 1 */ /* size: 88, cachelines: 2, members: 4 */ /* padding: 5 */ /* last cacheline: 24 bytes */ }; [acme< at >doppio pahole]$ pahole -C class_member build/pahole struct class_member { struct tag tag; /* 0 64 */ /* --- cacheline 1 boundary (64 bytes) --- */ char * name; /* 64 8 */ uint32_t offset; /* 72 4 */ uint8_t bit_offset; /* 76 1 */ uint8_t bit_size; /* 77 1 */ uint8_t bit_hole; /* 78 1 */ uint8_t bitfield_end:1; /* 79: 7 1 */ uint8_t visited:1; /* 79: 6 1 */ uint8_t accessibility:2;/* 79: 4 1 */ uint8_t virtuality:2; /* 79: 2 1 */ /* XXX 2 bits hole, try to pack */ uint16_t hole; /* 80 2 */ /* size: 88, cachelines: 2, members: 11 */ /* bit holes: 1, sum bit holes: 2 bits */ /* padding: 6 */ /* last cacheline: 24 bytes */ }; [acme< at >doppio pahole]$ pahole -C parameter build/pahole struct parameter { struct tag tag; /* 0 64 */ /* --- cacheline 1 boundary (64 bytes) --- */ char * name; /* 64 8 */ Dwarf_Off abstract_origin;/* 72 8 */ /* size: 80, cachelines: 2, members: 3 */ /* last cacheline: 16 bytes */ }; See? All of these classes (structs) contains the specified class (struct) "tag". And if you specify --recursive together with -i/--contains you'll get something more interesting: [acme< at >doppio pahole]$ pahole --recursive --contains tag build/pahole parameter ftype function lexblock function class_member array_type base_type namespace type class [acme< at >doppio pahole]$ See? 'class' is-a 'type' is-a 'namespace' is-a 'tag'. To see it more clearly use --expand_types: [acme< at >doppio pahole]$ pahole -C class --expand_types build/pahole struct class { struct type { struct namespace { struct tag { struct list_head { struct list_head * next; /* 0 8 */ struct list_head * prev; /* 8 8 */ } node; /* 0 16 */ struct list_head { struct list_head * next; /* 16 8 */ struct list_head * prev; /* 24 8 */ } hash_node; /* 16 16 */ /* typedef Dwarf_Off -> GElf_Off -> Elf64_Off -> uint64_t */ long unsigned int type; /* 32 8 */ /* typedef Dwarf_Off -> GElf_Off -> Elf64_Off -> uint64_t */ long unsigned int id; /* 40 8 */ const char * decl_file; /* 48 8 */ /* typedef uint16_t */ short unsigned int decl_line; /* 56 2 */ /* typedef uint16_t */ short unsigned int tag; /* 58 2 */ /* typedef uint16_t */ short unsigned int refcnt; /* 60 2 */ /* typedef uint16_t */ short unsigned int recursivity_level; /* 62 2 */ /* --- cacheline 1 boundary (64 bytes) --- */ } tag; /* 0 64 */ /* --- cacheline 1 boundary (64 bytes) --- */ const char * name; /* 64 8 */ struct list_head { struct list_head * next; /* 72 8 */ struct list_head * prev; /* 80 8 */ } tags; /* 72 16 */ /* typedef uint16_t */ short unsigned int nr_tags; /* 88 2 */ } namespace; /* 0 96 */ /* XXX last struct has 6 bytes of padding */ /* --- cacheline 1 boundary (64 bytes) was 32 bytes ago --- */ struct list_head { struct list_head * next; /* 96 8 */ struct list_head * prev; /* 104 8 */ } node; /* 96 16 */ /* typedef Dwarf_Off -> GElf_Off -> Elf64_Off -> uint64_t */ long unsigned int specification; /* 112 8 */ /* typedef size_t */ long unsigned int size; /* 120 8 */ /* --- cacheline 2 boundary (128 bytes) --- */ /* typedef size_t */ long unsigned int size_diff; /* 128 8 */ /* typedef uint16_t */ short unsigned int nr_members; /* 136 2 */ /* typedef uint8_t */ unsigned char declaration; /* 138 1 */ /* typedef uint8_t */ unsigned char definition_emitted:1; /* 139: 7 1 */ /* typedef uint8_t */ unsigned char fwd_decl_emitted:1; /* 139: 6 1 */ /* typedef uint8_t */ unsigned char resized:1; /* 139: 5 1 */ } type; /* 0 144 */ /* XXX last struct has 4 bytes of padding */ /* --- cacheline 2 boundary (128 bytes) was 16 bytes ago --- */ struct list_head { struct list_head * next; /* 144 8 */ struct list_head * prev; /* 152 8 */ } vtable; /* 144 16 */ /* typedef uint16_t */ short unsigned int nr_vtable_entries; /* 160 2 */ /* typedef uint8_t */ unsigned char nr_holes; /* 162 1 */ /* typedef uint8_t */ unsigned char nr_bit_holes; /* 163 1 */ /* typedef uint16_t */ short unsigned int padding; /* 164 2 */ /* typedef uint8_t */ unsigned char bit_padding; /* 166 1 */ /* XXX 1 byte hole, try to pack */ void * priv; /* 168 8 */ /* size: 176, cachelines: 3, members: 8 */ /* sum members: 175, holes: 1, sum holes: 1 */ /* paddings: 1, sum paddings: 4 */ /* last cacheline: 48 bytes */ }; Try --expand_pointers at home, say on struct task_struct on the Linux kernel 8-) For the lazy ones: [acme< at >doppio pahole]$ pahole -C task_struct --expand_types --expand_pointers vmlinux > http://oops.ghostprotocols.net/dwarves/pahole/vmlinux-expand_pointers-task_struct.txt http://vger.kernel.org/~acme/vmlinux-expand_pointers-task_struct.txt - Arnaldo -- 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

Re: Errors during a pfunct scan for amarokcollectionscanner andinkscape

Arnaldo Carvalho de Melo — 2008-06-16T18:14:18

Em Sun, Jun 15, 2008 at 03:02:33PM -0300, Arnaldo Carvalho de Melo escreveu: Fixed, I'm now adding the DW_TAG_typedef entries to the compile unit where the DW_TAG_subroutine_type is defined. This: dwarf_expr: unhandled 0x12 DW_OP_ operation is probably related to pure virtual base classes, this will require a bit more work but its something its in my TODO list for quite a while, so I may well implement support for location expressions. - Arnaldo -- 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

Re: Errors during a pfunct scan for amarokcollectionscanner andinkscape

Arnaldo Carvalho de Melo — 2008-06-15T18:02:33

Em Sun, Jun 15, 2008 at 02:13:27PM -0300, Arnaldo Carvalho de Melo escreveu: Really strange case: <1><6d90>: Abbrev Number: 5 (DW_TAG_subroutine_type) <6d91> DW_AT_sibling : <0x6dba> <2><6d95>: Abbrev Number: 6 (DW_TAG_formal_parameter) <6d96> DW_AT_type : <0x50> <2><6d9a>: Abbrev Number: 6 (DW_TAG_formal_parameter) <6d9b> DW_AT_type : <0x6d9f> <2><6d9f>: Abbrev Number: 11 (DW_TAG_typedef) <6da0> DW_AT_name : (indirect string, offset: 0x1a977): CleanupFunc <6da4> DW_AT_decl_file : 18 <6da5> DW_AT_decl_line : 46 <6da6> DW_AT_type : <0x6a71> <2><6daa>: Abbrev Number: 6 (DW_TAG_formal_parameter) <6dab> DW_AT_type : <0x50> <2><6daf>: Abbrev Number: 6 (DW_TAG_formal_parameter) <6db0> DW_AT_type : <0x6dba> <2><6db4>: Abbrev Number: 6 (DW_TAG_formal_parameter) <6db5> DW_AT_type : <0x66c6> This maps to something like this: typedef void (*CleanupFunc)(void *mem, void *data); struct Ops { void (*do_init)(); void *(*malloc)(std::size_t size); void *(*malloc_atomic)(std::size_t size); void *(*malloc_uncollectable)(std::size_t size); void *(*malloc_atomic_uncollectable)(std::size_t size); void *(*base)(void *ptr); void (*register_finalizer_ignore_self)(void *base, CleanupFunc func, void *data, CleanupFunc *old_func, void **old_data); Meaning that the typedef was not encoded right away, but postponed till just after its first use, i.e. in the parameter list of register_finalizer_ignore_self, as if it was local to this function. Later on it is again referenced, so its not local, as expected, I'll fix it, have just to check where to insert this typedef. - Arnaldo -- 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

Re: Errors during a pfunct scan for amarokcollectionscanner andinkscape

Arnaldo Carvalho de Melo — 2008-06-15T17:13:27

Em Sat, Jun 14, 2008 at 11:43:44AM +0200, Diego 'Flameeyes' Pettenò escreveu: The files provided in the tarball contains no debugging information, please check. I'll try installing the debunginfo for those packages in fedora rawhide. - Arnaldo -- 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

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,

Re: Another strange codiff output

Arnaldo Carvalho de Melo — 2008-05-27T22:02:06

Em Wed, May 21, 2008 at 02:04:26PM +0200, Diego 'Flameeyes' Pettenò escreveu: [acme< at >doppio pahole]$ pfunct -TVi --function send_ogg_buf modified.so | tail int stream_num); /* size=596, low_pc=0x30f3 */ // 646 } /* lexblock size=800 */ { /* send_ogg_buf+0x970 */ const buf_element_t * buf; // 686 const uint32_t * val; // 692 const char * str; // 693 } /* lexblock size=128 */ read_chapter_comment(demux_ogg_t * this, ogg_packet * op); /* size=859, low_pc=0x3460 */ // 657 }/* size: 3695, variables: 3, inline expansions: 1 (859 bytes) */ [acme< at >doppio pahole]$ in send_ogg_buf we got only one new inline, read_chapter_comment, and this one uses the DW_AT_ranges attribute: <2><552a>: Abbrev Number: 66 (DW_TAG_inlined_subroutine) <552b> DW_AT_abstract_origin: <0x5165> <552f> DW_AT_ranges : 0x4c0 <5533> DW_AT_call_file : 1 <5534> DW_AT_call_line : 657 IIRC this means that the the way the code in the inline was inserted into the target function (send_ogg_buf) wasn't linear... It would be a good idea to create a function that is not inline and includes just read_chapter_comment, produce an object and then disassemble it, then disassemble send_ogg_buf so that we could check the difference trying to validate the code in the dwarves that handles DW__AT_ranges, that is in inline_expansion__new, and that looks quite fishy :-\ send_header, had 13 inline expansions and now has just 1, the only one now is: <3><5afa>: Abbrev Number: 79 (DW_TAG_inlined_subroutine) <5afb> DW_AT_abstract_origin: <0x5600> <5aff> DW_AT_low_pc : 0x3e12 <5b07> DW_AT_high_pc : 0x40e5 <5b0f> DW_AT_call_file : 1 <5b10> DW_AT_call_line : 1337 <5b12> DW_AT_sibling : <0x5b80> That doesn't use DW_AT_ranges, so we can just do a 0x40e5 - 0x3e12 and get 712 bytes... We're not accounting lex block nesting, we have inline expansions inside lex blocks, working on that now. - Arnaldo -- 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

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,

Re: The strange ever-changing structure :)

Arnaldo Carvalho de Melo — 2008-05-12T17:54:39

CCing dwarves ML Em Mon, May 12, 2008 at 07:29:17PM +0200, Diego 'Flameeyes' Pettenò escreveu: 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> And another, that is local to the blend_yuv_grow_extra_data function and that has 56 bytes. <2><5d401>: Abbrev Number: 19 (DW_TAG_structure_type) <5d402> DW_AT_name : (indirect string, offset: 0x79c6): header_s <5d406> DW_AT_byte_size : 56 <5d407> DW_AT_decl_file : 1 <5d408> DW_AT_decl_line : 1107 <5d40a> DW_AT_sibling : <0x5d43b> I'm now thinking on how to properly support this... I think that the data structures in libdwarves are in the right shape, i.e. these structs already are in separate namespaces, I'll check now how pahole/codiff are handling this. - Arnaldo -- 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

Re: Unknown error 18446744073709551615

Arnaldo Carvalho de Melo — 2008-05-01T20:12:00

Em Thu, May 01, 2008 at 02:22:38AM +0200, Diego 'Flameeyes' Pettenò escreveu: Tried several variants for the URL, all gave me: [acme< at >doppio examples]$ wget http://www.flameeyes.eu/tmp/dwarves-error.tbz2 --2008-05-01 17:11:14-- http://www.flameeyes.eu/tmp/dwarves-error.tbz2 Resolving www.flameeyes.eu... 213.239.249.247 Connecting to www.flameeyes.eu|213.239.249.247|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2008-05-01 17:11:15 ERROR 404: Not Found. [acme< at >doppio examples]$ Can you please also make available the openrc rc binary that produces this error? - Arnaldo -- 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

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

Re: "File has no CTF section."

Arnaldo Carvalho de Melo — 2008-04-24T15:56:48

Em Thu, Apr 24, 2008 at 10:25:11AM -0500, Florin Iucha escreveu: Poooong, sorry for the delay, will try again to fix this today. - Arnaldo -- 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

Re: "File has no CTF section."

Florin Iucha — 2008-04-24T15:25:11

Pinnnggg! florin

Re: [PATCH] Add support for filtering classes based on name

Dave Rigby — 2008-04-21T15:32:52

On 21 Apr 2008, at 16:27, Arnaldo Carvalho de Melo wrote: Sure, that's fine. I'm new to this git lark, so wasn't aware of that :) Dave Rigby -- 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

Re: [PATCH] Add support for filtering classes based on name

Arnaldo Carvalho de Melo — 2008-04-21T15:43:57

Em Mon, Apr 21, 2008 at 04:32:52PM +0100, Dave Rigby escreveu: Then thanks again, works like a charm: [acme< at >doppio pahole]$ pahole --sizes -y argp build/pahole argp_child321 argp560 argp_state961 argp_option482 [acme< at >doppio pahole]$ Applied and pushed out, please do a git-pull :-) - Arnaldo -- 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

Re: [PATCH] Add support for filtering classes based on name

Arnaldo Carvalho de Melo — 2008-04-21T15:27:54

Em Mon, Apr 21, 2008 at 02:22:14PM +0000, Dave Rigby escreveu: Thanks a lot! May I add a: Signed-off-by: Dave Rigby public.gmane.org> To this commit? What this means is described in the Linux kernel sources, where this convention was originated: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/SubmittingPatches;hb=HEAD Basically: 12) Sign your work To improve tracking of who did what, especially with patches that can percolate to their final resting place in the kernel through several layers of maintainers, we've introduced a "sign-off" procedure on patches that are being emailed around. The sign-off is a simple line at the end of the explanation for the patch, which certifies that you wrote it or otherwise have the right to pass it on as a open-source patch. The rules are pretty simple: if you can certify the below: Developer's Certificate of Origin 1.1 By making a contribution to this project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. then you just add a line saying Signed-off-by: Random J Developer public.gmane.org> using your real name (sorry, no pseudonyms or anonymous contributions.) Some people also put extra tags at the end. They'll just be ignored for now, but you can do this to mark internal company procedures or just point out some special detail about the sign-off. -- 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

[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

Re: "File has no CTF section."

Arnaldo Carvalho de Melo — 2008-03-25T17:57:49

Em Tue, Mar 25, 2008 at 12:24:14PM -0500, Florin Iucha escreveu: ACK, reproduced here, will investigate, strange indeed. - Arnaldo -- 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

Re: "File has no CTF section."

Florin Iucha — 2008-03-25T17:24:14

Re: "File has no CTF section."

Arnaldo Carvalho de Melo — 2008-03-25T16:41:03

Em Tue, Mar 25, 2008 at 10:24:03AM -0500, Florin Iucha escreveu: Argh, I have to fix that, this just means that the file doesn't have DWARF info _nor_ CTF info. can you try with: # binutils readelf -w i build/pahole # elfutils eu-readelf -w i build/pahole indeed, misleading it is, fixing now... done Possibly, but can you make these two object files available somewhere? I'd like to take a look... -- 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)'

Re: Little request: a notice of new releases :)

Arnaldo Carvalho de Melo — 2008-03-23T00:59:39

Em Wed, Mar 12, 2008 at 12:29:34PM +0100, Diego 'Flameeyes' Pettenò escreveu: Sorry, I'll do that in the future. Perhaps after polishing the CTF support :-) - Arnaldo -- 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