On Tue, Nov 6, 2018 at 9:40 AM Tom Hughes <t...@compton.nu> wrote: > On 06/11/2018 17:38, Rafael Antognolli wrote: > > > > > > On Tue, Nov 6, 2018 at 9:25 AM Tom Hughes <t...@compton.nu > > <mailto:t...@compton.nu>> wrote: > > > > On 06/11/2018 17:02, Rafael Antognolli wrote: > > > > > My (limited) understanding is that valgrind's mremap doesn't let > me > > > remap an address that was allocated by the ioctl, since valgrind > > doesn't > > > "own" that memory. Is there some way around this, or this is never > > > supposed to work? > > > > > > I don't see any reason why it shouldn't IF the ioctl wrapper is > > correctly written to update valgrind's internal state and record > > the mapping that it creates. > > > > > > By that, do you mean using VALGRIND_MALLOCLIKE_BLOCK and > > VALGRIND_FREELIKE_BLOCK? If so, that's already happening but no > > luck so far. > > No I mean that internally valgrind keeps track of the mappings > in the process address space in the aspacemgr component and if a > system calls creates a mapping then the post handler for that > system call needs to update that. >
Oh, so this would be in valgrind's code, right? I do see VKI_DRM_IOCTL_I915_GEM_MMAP_GTT in the code, but the ioctl in question (that I can't find there) is DRM_IOCTL_I915_GEM_MMAP. So maybe with that it should work? > Tom > > -- > Tom Hughes (t...@compton.nu) > http://compton.nu/ >
_______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
