Right. I'd also like to point out that I carried out some additional
experiments using variations of the program in the issue description, with
bizarre results, mips64. I changed the value of the pointer to 0x7f7df38c
to increase the alignment a bit and then did the following experiments:
It's no less reasonable than doing an mmap() with a fixed address -- if
the application knows what it's doing then it's fine. It's just that it
bumps into our internal implementation details of (a) doing an mmap to
reserve the full 32-bit space we want to allow the guest to do and (b)
just passing
Mapping an arbitrary address in the memory takes the risk to have this address
already in use by the loader or a library.
Where does this address come from?
Why the qemu-mips program doesn't call shmat() with NULL?
--
You received this bug notification because you are a member of qemu-
Here's the end of strace output for running through qemu-i386:
shmget(IPC_PRIVATE, 688128, IPC_CREAT|IPC_EXCL|0666) = 72810572
shmctl(72810572, IPC_STAT, {shm_perm={uid=1000, gid=1000, mode=0666, key=0,
cuid=1000, cgid=1000}, shm_segsz=688128, shm_cpid=10438, shm_lpid=0,
shm_nattch=0,
I think analysis in comment #1 is correct: If I use "shmat(id, at,
SHM_REMAP)" it works.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1462640
Title:
shmat fails on 32-to-64 setup
Status in QEMU:
For comparison, the strace output when running natively:
shmget(IPC_PRIVATE, 688128, IPC_CREAT|IPC_EXCL|0666) = 72843341
shmctl(72843341, IPC_64|IPC_STAT, {shm_perm={uid=1000, gid=1000, mode=0666,
key=0, cuid=1000, cgid=1000}, shm_segsz=688128, shm_cpid=10883, shm_lpid=0,
shm_nattch=0,
Yes, that is correct, but the behavior is still different between
"native" execution and execution through qemu-i386. Changing the pointer
to be initialized with 0xf38ea000 (essentially truncating it manually)
does not change anything:
~/qemu$ gcc -m32 shm_bug.c -o shm_bug32
shm_bug.c: In
Erm isn't your 64bit pointer being truncated when you build for 32 bit?
** Tags added: mips testcase
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1462640
Title:
shmat fails on 32-to-64 setup
I can confirm that this bug still exists in the current qemu master
(short commit ID 0050f9978e):
~/qemu$ gcc -m32 shm_bug.c -o shm_bug32
shm_bug.c: In function ‘main’:
shm_bug.c:12:24: warning: initialization makes pointer from integer without a
cast [-Wint-conversion]
const void *at =
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1462640
Title:
shmat
Which version of QEMU did you use here? Does it still reproduce with the
latest version of QEMU?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
11 matches
Mail list logo
