Quoting Chris Wilson (2017-07-14 00:12:25) > gdb uses ptrace() to peek and poke bytes of the target's address space. > The driver must implement an vm_ops->access() handler or else gdb will > be unable to inspect the pointer and report it as out-of-bounds. > Worse than useless as it causes immediate suspicion of the valid GTT > pointer, distracting the poor programmer trying to find his bug. > > Since we want that the access of the GTT mmap to be invisible to the > client, we try to minimise any state changes. Instead of binding the > object into the GGTT (causing gpu stalls, cache domain changes), we > simply kmap the backing storage and clflush to ensure coherency. > This limits us to only accessing objects backed by pages, which covers > all user objects for the time being. First question is whether or not we should wait for the gpu. Using peekdata/pokedata implies the target thread is stopped, we could infer that also means that any gpu tasks are also stopped for the client. (To be accurate we would have to flush the requests when the tracee handles SIGSTOP.) But without the serialisation, it does mean that the data may changed underneath the tracer, which is not intended. (Now there are other means for that data to change, it is shared between clients.) I'm thinking we actually do want the serialisation -- it should reduce the potential strange behaviour under gdb. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
