blob: 87bafd8a46b512a1bcf9bf42fa93cf215a475825 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
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
|