If I run the exact same version of my Valgrind based tool on the exact same target binary but on different disk drives I get a different result. I understand that different block sizes on the two drives might cause different paths through the C runtime, but I would expect the user program to have the exact same results.
The difference appears to be the processing of the instruction (on AMD64): callq 400c50 <fputs@plt> I understand how the plt/got code works in general, but I am curious as to how Valgrind treats it. I am using the trace-flags option to observe the program flow of control. So the two program executions are basically matching until we get to the second time the program calls fputs. In one case, the next SB processed starts with the instruction after the call. In the other case, it appears the indirect call sends us out into the middle of the clib routine _IO_default_xsputn as that is the next SB processed. Then the next SB after that one is the instruction after the call as in the first case. As my program is using Valgrind to do code instrumentation, the addition of the extra xsputn SB has a knock on effect that changes the program output. I am assuming that previously translated SBs are 'skipped' in the trace-flags output. Is there an option to show that SB <number> is being executed again? That is, show the complete flow of control for the program? Assuming my program has not trashed Valgrind in some way, could it be possible that _IO_default_xsputn is a portion of the code for fputs that was not needed in one case do to the difference in disk block sizes? Thank you, Mark Roberts UW PLSE group _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
