On Wed, 2015-12-09 at 13:41 -0800, Nikolaus Rath wrote:
> I believe this is the relevant objdump output - but again I don't understand
> it. Does it tell you anything?
>
> <1><a8f8c>: Abbrev Number: 42 (DW_TAG_subprogram)
> <a8f8d> DW_AT_decl_line : 1916
> <a8f8f> DW_AT_decl_file : 1
> <a8f90> DW_AT_declaration : 1
> <a8f91> DW_AT_name : (indirect string, offset: 0xa5fc):
> h5dump_attr_int
> <a8f95> DW_AT_external : 1
> <a8f96> DW_AT_inline : 1 (inlined)
So, we have now clearly confirmed that the wrong stacktrace is caused by
valgrind not understanding that h5dump_attr_int has been inlined.
What you could do is to modify storage.c line 668 put a (1) instead of
(0) :
if (0) VG_(message)
(Vg_DebugMsg,
"addInlInfo: fn %s inlined as addr_lo %#lx,addr_hi %#lx,"
"caller fndn_ix %u %s:%d\n",
inlinedfn, addr_lo, addr_hi, fndn_ix,
ML_(fndn_ix2filename) (di, fndn_ix), lineno);
This will then trace the inlined call information.
If this inlined info is properly understood and recorded, you should
see some information produced that tells that h5dump_attr_int
has been inlined around the program counter of:
==2047== by 0xB99FC6: taehdf5_mp_h5append_data_double_0d_ (taehdf5.f90:1936)
If this is not recorded, then it is the valgrind dwarf reader that likely has
a problem.
Otherwise, it is the unwinder which does not properly use the inline info.
Philippe
------------------------------------------------------------------------------
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
