Why can't gdb read io_uring_cqe contents?

Question

I am trying out loti-examples (Lord of the Uring) commit 8724d47 and liburing commit 7ff4fee on Ubuntu 20.04 with mainline kernel 5.12.

I use the following patch for loti-examples to have a better debugging experience:

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 0c857b6..0afcbe3 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -2,6 +2,8 @@ cmake_minimum_required(VERSION 3.15)
 project(liburing_examples C)
 
 set(CMAKE_C_STANDARD 99)
+set(CMAKE_BUILD_TYPE Debug)
+SET(CMAKE_CXX_FLAGS  "${CMAKE_CXX_FLAGS} -ggdb3") 
 
 add_executable(probe probe.c)
 target_link_libraries(probe uring)

After building, I launch gdb build/webserver_liburing, here is what I am doing:

(gdb) start
[omitted]
(gdb) break io_uring_sqe_set_data
Breakpoint 2 at 0x5555555556ec: file /usr/include/liburing.h, line 200.
(gdb) break 441
Breakpoint 3 at 0x555555556acb: file /home/janus/Skrivebord/artemis/loti-examples/webserver_liburing.c, line 441.
(gdb) c
Continuing.
Minimum kernel version required is: 5.5
Your kernel version is: 5.12
ZeroHTTPd listening on port: 8000

Breakpoint 2, io_uring_sqe_set_data (sqe=0x7ffff7fc2000, data=0x55555555c6b0) at /usr/include/liburing.h:200
200     sqe->user_data = (unsigned long) data;
(gdb) p data
$1 = (void *) 0x55555555c6b0
(gdb) c
Continuing.

Breakpoint 3, server_loop (server_socket=3) at /home/janus/Skrivebord/artemis/loti-examples/webserver_liburing.c:441
441         struct request *req = (struct request *) io_uring_cqe_get_data(cqe);
(gdb) p cqe->user_data
Cannot access memory at address 0x7ffff7fc6140
(gdb) p ret
$5 = 0

I am trying to verify that the request pointer that is sent on the submission queue is the same one that comes back on the the completion queue.

So at the breakpoint at line 441, you can see from the last line of gdb output, that the call to io_uring_wait_cqe was successful, since its return value ret is zero. So why can't I read cqe->user_data with gdb? I'd expect it to contain the same address that was submitted to the submission queue on the first breakpoint, bound to the name data at that time.

EDIT May 12th:

Mark Plotnick hinted that the address could be I/O mapped, and indeed it is:

(gdb) x cqe
0x7ffff7fc6140: Cannot access memory at address 0x7ffff7fc6140
(gdb) info proc mappings
[...]
  0x7ffff7fc2000     0x7ffff7fc6000     0x4000 0x10000000 anon_inode:[io_uring]
  0x7ffff7fc6000     0x7ffff7fc9000     0x3000        0x0 anon_inode:[io_uring]
[...]