1 files changed, 60 insertions, 0 deletions
diff --git a/results/classifier/118/device/1813307 b/results/classifier/118/device/1813307
new file mode 100644
index 000000000..87bafd8a4
--- /dev/null
+++ b/results/classifier/118/device/1813307
@@ -0,0 +1,60 @@
+device: 0.893
+performance: 0.777
+graphic: 0.635
+network: 0.627
+architecture: 0.581
+ppc: 0.576
+semantic: 0.539
+files: 0.468
+i386: 0.455
+x86: 0.404
+kernel: 0.390
+register: 0.374
+vnc: 0.361
+socket: 0.349
+PID: 0.349
+arm: 0.330
+hypervisor: 0.327
+mistranslation: 0.315
+risc-v: 0.297
+permissions: 0.294
+boot: 0.282
+debug: 0.271
+peripherals: 0.249
+VMM: 0.203
+virtual: 0.201
+KVM: 0.200
+TCG: 0.199
+user-level: 0.145
+assembly: 0.102
+
+util/path.c/follow_path() does not handle "/" well
+
+Hello,
+
+I noticed that qemu does not handle "/" very well in follow_path().
+
+Specifically, I was trying to run gdbserver under qemu, and it failed inside its implementation of __getcwd.
+
+Indeed it does something like
+  if (__lstat ("/", &st) < 0)
+.....
+and then loops from current dir toward the top using lstat("..")
+
+On qemu side, lstat forwards the request to follow_path() in util/path.c, and when passed "/", it returns the path in QEMU_LD_PREFIX (which was the top of my sysroot).
+OTHT, the series of lstat("..") finally reaches the real device root because it's not recognized as "/" in follow_path(), so this is inconsistent and __getcwd fails.
+
+I suppose there's a good reason for returning QEMU_LD_PREFIX when asking for "/", but why is it so?
+
+If there's no good reason, maybe the behaviour could be changed to map "/" to "/" ?
+
+Thanks
+
+
+This is an automated cleanup. This bug report has been moved to QEMU's
+new bug tracker on gitlab.com and thus gets marked as 'expired' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/162
+
+