On 12/09/2015 02:15 PM, Philippe Waroquiers wrote: > On Wed, 2015-12-09 at 22:59 +0100, Philippe Waroquiers wrote: > >> 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. > What you can also do is to use > (gdb) monitor v.info location <address> > > When address is some code, it will print the function/file/line nr > (and if address corresponds to inlined calls, it should describe all > what is inlined). > > For example, for the test memcheck/tests/inlinfo, I obtain: > (gdb) mo v.info loc 0x80486DC > Address 0x80486dc is in the Text segment of memcheck/tests/inlinfo > ==8004== at 0x80486DC: fun_d (inlinfo.c:7) > ==8004== by 0x80486DC: fun_c (inlinfo.c:15) > ==8004== by 0x80486DC: fun_b (inlinfo.c:21) > ==8004== by 0x80486DC: fun_a (inlinfo.c:27) > ==8004== by 0x80486DC: main (inlinfo.c:66) > > If the inline info is recorded and used properly, the above command > should give the inlining and inlined functions for the relevant program > counter.
Apparently the info is not used correctly then: (gdb) monitor v.info location 0xB99FC6 Address 0xb99fc6 is in the Text segment of /mnt/nfs-home/nrath/Q2D/LamyRidge/src/model/build/LR_model ==18278== at 0xB99FC6: taehdf5_mp_h5append_data_double_0d_ (taehdf5.f90:1936) (gdb) Best, -Nikolaus ------------------------------------------------------------------------------ _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
