Em Sun, Jun 15, 2008 at 03:02:33PM -0300, Arnaldo Carvalho de Melo escreveu: > Em Sun, Jun 15, 2008 at 02:13:27PM -0300, Arnaldo Carvalho de Melo escreveu: > > Em Sat, Jun 14, 2008 at 11:43:44AM +0200, Diego 'Flameeyes' Pettenò escreveu: > > > > > > 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@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! > > 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. 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
