gdb的watchpoint在系统调用中被修改似乎不会被触发

今天遇到一个越界写问题，覆盖了栈底的金丝雀值，导致运行时报“*** stack smashing detected ***”。一开始尝试用gdb的watchpoint定位，但就是眼睁睁的看着运行结束后金丝雀值被修改而没有触发watchpoint，最后无奈一行行的定位，发现是一个ioctl导致的越界写。
后来我试着研究watchpoint未被触发的原因，在GDB的官方Wiki发现这么一句话：

x86 processors support setting watchpoints on I/O reads or writes. However, since no target supports this (as of March 2001), and since enum target_hw_bp_type doesn’t even have an enumeration for I/O watchpoints, this feature is not yet available to GDB running on x86.

官方Wiki在2001年说x86上IO读写操作不支持设置watchpoint，我就写了个demo：

#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>

const char *filepath = "/home/imred/hw.txt";

int main()
{
    int fd = open(filepath, O_RDONLY);
    if (fd < 0) {
        perror("open file failed");
        exit(EXIT_FAILURE);
    }

    char buf[6] = {0};
    int result = read(fd, buf, sizeof(buf) - 1);
    if (result != sizeof(buf) - 1) {
        printf("result: %d\n", result);
        perror("read file failed");
        exit(EXIT_FAILURE);
    }
    else {
        printf("read ok: %s\n", buf);
    }

    close(fd);
    return 0;
}

发现果真如此，在现在（8102年），IO读写的watchpoint仍然不支持。对buf变量的第一个字节设置watchpoint，read调用前后值已经变了，但是没有命中。
由于ioctl也不是IO读写操作，而ioctl和IO读写操作都是系统调用，因此怀疑系统调用中的watchpoint也不支持，我又接着测试了其他系统调用，直接用syscall指定调用号，demo如下：

#include <asm/prctl.h>
#include <stdio.h>
#include <syscall.h>
#include <unistd.h>

int main()
{
    unsigned long addr = 0;
    syscall(__NR_arch_prctl, ARCH_GET_FS, &addr);
    printf("fs: %p\n", (void *)addr);
    return 0;
}

发现结果是一样的，addr被修改了，但是addr的watchpoint没有命中。
由于对gdb的watchpoint内部原理不了解，所以具体原因我也说不上来。不过推测是因为gdb是一个用户空间的工具，对运行在内核空间的系统调用代码无能为力。