On Wed, 2007-09-19 at 00:07 +0200, Alexander Graf wrote:
On Sep 18, 2007, at 11:49 PM, Thayne Harbaugh wrote:
On Tue, 2007-09-18 at 21:11 +0200, Alexander Graf wrote:
On Sep 18, 2007, at 8:25 PM, Thayne Harbaugh wrote:
On Tue, 2007-09-18 at 15:53 +0200, Ronald wrote:
Thayne Harbaugh schreef:
<SNIP>
./i386-linux-user/qemu-i386 --help
Segmentation fault
From GDB:
Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0 0x0000000000000000 in ?? ()
#1 0x00000000600575ed in __libc_csu_init ()
#2 0x00002b826c660ade in __libc_start_main () from /lib/
libc.so.6
#3 0x00000000600050e9 in _start ()
<SNIP>
We had this on the list some months ago.
I'll dig for that.
As far as I recall this
correctly the problem is the linker script. Just take a look at the
suse source rpm where we replace that one, so it works with x86_64.
Thanks for the guidance.
Be prepared for breakage though, as linux-user on 64-Bit hosts does
not work properly.
What about it doesn't work properly? Do you have some links for the
list archives?
Mostly syscalls that return 64-bit pointers. So for example mmap is
broken. You can find a patch for x86_64 for that in the rpm or on the
list as well, which does not fix the issue on ppc64 or ia64 though.
As far of what I see in the code and I can see when executing programs
in linux-user on x86_64, mmap may be the safer 64 bits call... There
seem to be a hack for alpha, sparc, x86_64, ia64 and mips (don't know
why ppc64 is not in the list...) that force the requested address
to be
in the 32 bits address space (but does not seem to force the MAP_FIXED
flag...).
Additionally there is an IPC call that does an mmap in the end, where
you can not force it to return 32-bit values, so this can not be
easily fixed. The IA64-IA32 emulator actually does have an approach
for this, but I did not have the time to take a deeper look into
that.
Well, I noticed that there seem to be numerous problems in IPC, not
especially related to 64 bits.
As I reported yesterday, there seem to be some confusions between
short/int and long types for all the targets I checked. There also
seem
to be 64 bits issues, in addition...
I can see no mmap in IPC calls, but I noticed there is a problem for
32/64 bits compatibility with the shmat call. I guess this can be
fixed
exactly in the same way mmap was fixed, forcing the requested
address to
a known area when the caller does not specify any...