]> git.ipfire.org Git - thirdparty/valgrind.git/commit
Presently, Valgrind (non-client) code that wants to use the stat
authorJulian Seward <jseward@acm.org>
Tue, 19 Aug 2008 07:03:04 +0000 (07:03 +0000)
committerJulian Seward <jseward@acm.org>
Tue, 19 Aug 2008 07:03:04 +0000 (07:03 +0000)
commite5150447d708b1d48f66d6ac273f8e62b515f07e
tree3ea7d6e3548c366debd565ca33e140abcf08a5e4
parent811f1023887913f989a1041419ae339d73086cc0
Presently, Valgrind (non-client) code that wants to use the stat
family of syscalls is impossible to write in a way that's portable and
correct.  On some targets (eg x86-linux) you need to do sys_stat64 and
receive the results in a 'struct vki_stat64'.  But on other targets
(eg amd64-linux) neither sys_stat64 nor 'struct vki_stat64' exist.

This commit adds a new type, 'struct vg_stat', which contains 64 bit
fields in all the right places, and makes VG_(stat) and VG_(fstat) use
it.  This means callers to the two functions no longer need to worry
about the is-it-64-bit-clean-or-not question, since these routines
reformat the received data into a'struct vg_stat'.  Kind of like what
glibc must have been doing for decades.

This (indirectly) fixes a bug on x86-linux, in which m_debuginfo would
sometimes fail to read debug info, due to VG_(di_notify_mmap) using
VG_(stat) (hence sys_stat) on the file, which failed, and when in fact
it should have used sys_stat64.  Bug reported and tracked down by
Marc-Oliver Straub.

git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8522
coregrind/m_commandline.c
coregrind/m_debuginfo/debuginfo.c
coregrind/m_debuginfo/readelf.c
coregrind/m_libcfile.c
coregrind/m_ume.c
coregrind/pub_core_libcfile.h
include/pub_tool_libcfile.h