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@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! die__create_new_subroutine_type: DW_TAG_typedef @ <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,

Diego "Flameeyes" Pettenò
http://blog.flameeyes.eu/

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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html