[Mesa-dev] [PATCH RFC] intel/tools: new intel_sanitize_gpu tool

[Scott D Phillips]

"Rogovin, Kevin" <kevin.rogovin at intel.com> writes:

> HI Scott,
>
>  I like the idea of making this a pre-loadable .so as it lets it get
>  reused for anything using the kernel interface using GEM's. However,
>  there are a few bits, that if addressed, would make this perfect IMO:
>
>   1. It needs a way of being able to label the GEMs (brw_bufmgr.c
>   provides this). The current code below will just tell us which ioctl
>   had a bad thing happen to a GEM BO, but it won't tell us which GEM
>   easily. Admittedly a debug session will tell us the handle of the
>   GEM, but then it is quite icky to figure what the GEM BO was for
>   (OpenGL BO, scratch BO, etc.)

I'm not sure it's really that imperative that a name is in the log
print, anv doesn't even have such labels. And you would still need to
dig in with other techniques to find out what's actually
happening. Also, in a gdb session you can get to the i965 name (or
whatever other info) in just a few commands:

(gdb) p handle
$1 = 9
(gdb) f 4
#4  0x00007ffff12ef4b5 in submit_batch (brw=0x7ffff7f98040, in_fen
    ce_fd=-1, out_fence_fd=0x0) at ../src/mesa/drivers/dri/i965/in
    tel_batchbuffer.c:957
957           ret = execbuffer(dri_screen->fd, batch, hw_ctx,
(gdb) p hash_find_bo(brw->bufmgr->handle_table, $1)->name
$2 = 0x7ffff1af7f10 "prime"

I think the really critical information is just that any out-of-bounds
write happened.

>  2. In an ideal world, the .so will work perfectly with other
>  pre-loadable .so's that intercept ioctl as well (for example aub or
>  the batchbuffer logger I made); I freely admit that I am a touch
>  fuzzy on the LD_PRELOAD rules, but it looks like one cannot use this
>  tool at the same time as any other tool that tries to intercept
>  ioctl's (though to be fair, those tools as well don't work with
>  others either I think).

This does work, each of these hook libraries is finding the next library
by using the pseudo-handle of RTLD_NEXT in the dlsym() call (instead of
a specific other library that was dlopen()ed). They might do other
things to mess each other up, but the hooking technique itself is
composable.

-- 
scott-ph