From 027bca7927d96f0669ce346c26154475902dad8a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ciro=20Santilli=20=E5=85=AD=E5=9B=9B=E4=BA=8B=E4=BB=B6=20?=
 =?UTF-8?q?=E6=B3=95=E8=BD=AE=E5=8A=9F=20=E5=8C=85=E5=8D=93=E8=BD=A9?=
 <ciro.santilli@gmail.com>
Date: Tue, 16 Jan 2018 17:30:22 +0000
Subject: [PATCH] Update gdbserver.md

---
 gdbserver.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gdbserver.md b/gdbserver.md
index 64804f1..e6af3b7 100644
--- a/gdbserver.md
+++ b/gdbserver.md
@@ -76,7 +76,7 @@ QEMU `-gdb` GDB breakpoints are set on virtual addresses, so you can in theory d
 - <https://stackoverflow.com/questions/26271901/is-it-possible-to-use-gdb-and-qemu-to-debug-linux-user-space-programs-and-kernel>
 - <https://stackoverflow.com/questions/16273614/debug-init-on-qemu-using-gdb>
 
-The only use case I can see for this is to debug the init process (and have fun), otherwise, why wouldn't you just use `gdbserver`? Known of direct userland debugging:
+The only use case I can see for this is to debug the init process (and have fun), otherwise, why wouldn't you just use `gdbserver`? Known limitations of direct userland debugging:
 
 -   the kernel might switch context to another process, and you would enter "garbage"