Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 22 Apr 1999 10:51:54 +1000
From:      Andrew Reilly <andrew@lake.com.au>
To:        freebsd-hackers@freebsd.org
Subject:   mmap() vs wine-990214
Message-ID:  <99042211015406.43091@gurney.reilly.home>

next in thread | raw e-mail | index | archive | help
Hi all,

I had been running -2.2.8 and wine-9807xx for some time.  Aparent stability
and improvements to both encouraged me to upgrade to the current releases
of both.  I'm pretty happy with 3.1-STABLE, but the applications I used to
run under wine (Win32 console applications: the Motorola DSP development
tools) now don't (run).  These applications are all stripped of relocation
information, and the problem appears to be that wine can't load them into
the appropriate memory locations.

After turning on some debugging trace, and adding a bit more of my own, I
see the following:

X-Newsreader: knews 1.0b.1
Reply-To: andrew@lake.com.au
Organization: Lake DSP
References: <7fj9gp$9o3$1@m2.c2.telstra-mm.net.au>
    <7fjd5f$f1m@faui11.informatik.uni-erlangen.de>
    <7fllo8$t8k$1@m2.c2.telstra-mm.net.au>
From: andrew@gurney.reilly.home (Andrew Reilly)
Subject: Re: PE_LoadImage wants to relocate "not relocatable" executables
Newsgroups: comp.emulators.ms-windows.wine

In article <7fllo8$t8k$1@m2.c2.telstra-mm.net.au>,
	andrew@gurney.reilly.home (Andrew Reilly) writes:
> Here's the last bit of the -debugmsg +win32 trace.  Sorry about
> the long lines...

Just to make matters more interesting, I added a few more trace
statements, and turned on file debugging, because FILE_dommap
seems to be where this particular piece of action is.  The
relevant (I think) last piece of trace is now:

trace:file:FILE_DoOpenFile (asm56300.exe): OK, return = 19
trace:virtual:CreateFileMapping32A (13,0x0,08000002,0000000000000000,(null))
trace:virtual:MapViewOfFileEx handle=14 size=60000 offset=0
trace:file:FILE_dommap mmap(0,60000,1,2,5,0) = trace:file:FILE_dommap 28a10000
View: 28a10000 - 28a6ffff 19 @ 00000000
      28a10000 - 28a6ffff c-r--
trace:win32:calc_vma_size Dump of segment table
trace:win32:calc_vma_size    Name    VSz  Vaddr     SzRaw   Fileadr  *Reloc *Lineum #Reloc #Linum Char
trace:win32:calc_vma_size    .text: 4e2a0 00001000 0004e400 00000400 00000000 00000000 0000 0000 60000020
trace:win32:calc_vma_size   .rdata: 0690 00050000 00000800 0004e800 00000000 00000000 0000 0000 40000040
trace:win32:calc_vma_size    .data: 18244 00051000 00010400 0004f000 00000000 00000000 0000 0000 c0000040
trace:win32:calc_vma_size   .idata: 05a2 0006a000 00000600 0005f400 00000000 00000000 0000 0000 c0000040
fixme:win32:PE_LoadImage Try VirtualAlloc(0x00400000, 0x0006a600, MEM_RESERVE | MEM_COMMIT, PAGE_EXECUTE_READWRITE )
trace:virtual:VirtualAlloc 00400000 0006a600 3000 00000040
trace:virtual:VirtualAlloc base = 0x00400000, size = 0x0006b000
trace:file:FILE_dommap mmap(400000,6b000,7,1002,-1,0) = trace:file:FILE_dommap 28a70000
trace:virtual:VirtualAlloc We couldn't get the address we wanted: 0x28a70000
vs 0x00400000
fixme:win32:PE_LoadImage VirtualAlloc result = 0x00000000
fixme:win32:PE_LoadImage Need to relocate F:\BIN\WINEBIN\ASM56300.EXE, but no relocation records present (stripped during link).
wine: can't exec 'asm56300.exe': error=0


OK, so I guess that the questions that need to be asked are:

a) Why can't FreeBSD's mmap() give me a block at 0x00400000?

b) Why are we asking for 0x00400000 when the Vaddr of the program is 0x1000?

c) Why isn't everyone else falling over this one straight away, given that it
   seems to be the normal situation for Win32 console applications?

d) How did it ever work before?  Could this be a FreeBSD-3.1 vs
   2.2.8 thing, rather than a wine 990214 vs 9807xx thing?

The mmap(2) manual page says (of MAP_FIXED, which isn't being used here)

[EINVAL]  
MAP_FIXED was specified and the addr parameter was not page aligned,
or part of the desired address space resides out of the valid address space
for a user process.

But none of the See Also pages would tell me what constituted a valid
address space for a user process.

Clues, hints, hope?

-- 
Andrew Reilly


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?99042211015406.43091>