Re: [Qemu-devel] Insta-segfault! i386-linux-user

[Alexander Graf <agraf@suse.de>]

On Sep 19, 2007, at 12:41 AM, J. Mayer wrote:

> 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...).

On x86_64 there is a flags for mmap that forces it to only use 32  
bits. That one is way easier but does not exist on other architectures.

>
>> 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...
>

This is what the IA64 emulator does and which is broken in qemu. Some  
months ago I sent some example programs to trigger this bug which  
actually only occured when I used threading. Just take a look at  
do_shmat in the ipc/shm.c in the linux kernel. The MAP_FIXED flag  
should work here, but the MAP_32BIT one is not available. I really  
don't remember which exact part broke, but I switched to using a 32- 
bit host for linux-user then and everything magically worked.

Cheers,

Alex