Thinking about what Fabian and Marcus hit...
Would it be possible to just have a dummy executable which allocates the 256MB chunk of memory from 11/22, linked to the same libs as the main wine-{k,p}thread, but having that executable not actually used?
That way, we still gain the prelink workaround by reserving the memory, but Wine should continue to work on computers with less memory, or those who do not overcommit memory.
Vincent
Vincent Béron vberon@mecano.gme.usherb.ca writes:
Would it be possible to just have a dummy executable which allocates the 256MB chunk of memory from 11/22, linked to the same libs as the main wine-{k,p}thread, but having that executable not actually used?
I don't see how, if the executable isn't used it won't do any good. What we need is a way to reserve the memory but not the swap space; but I don't think we can do that simply with a bss hack, it will require a linker script which is a major pain.
On Sat, 2003-12-13 at 20:21, Alexandre Julliard wrote:
I don't see how, if the executable isn't used it won't do any good. What we need is a way to reserve the memory but not the swap space; but I don't think we can do that simply with a bss hack, it will require a linker script which is a major pain.
Well, I asked this before but didn't get an answer - why can't we work with Jakub to have some new ELF flag/section to reserve a particular area of memory for the win32 binary?
Hmm, also, what happens if the binary is >256mb? For instance, some very large installers can go beyond that size. How does that work on Windows?
Mike Hearn mike@theoretic.com writes:
Well, I asked this before but didn't get an answer - why can't we work with Jakub to have some new ELF flag/section to reserve a particular area of memory for the win32 binary?
Of course we can, I was trying to find a way that would work today, without requiring upgrading to CVS binutils.
Also, frankly, I've spent the last year chasing glibc breakages, and I don't particularly feel like spending the next year chasing kernel breakages. I was kind of hoping someone else would pick that fight, so I could go back to writing some real Wine code for a change...
Hmm, also, what happens if the binary is >256mb? For instance, some very large installers can go beyond that size. How does that work on Windows?
Just make the array larger. I chose 256Mb because I haven't seen a binary larger than that, but if you have seen one feel free to fix the size.
Le sam 13/12/2003 à 15:21, Alexandre Julliard a écrit :
Vincent Béron vberon@mecano.gme.usherb.ca writes:
Would it be possible to just have a dummy executable which allocates the 256MB chunk of memory from 11/22, linked to the same libs as the main wine-{k,p}thread, but having that executable not actually used?
I don't see how, if the executable isn't used it won't do any good. What we need is a way to reserve the memory but not the swap space; but I don't think we can do that simply with a bss hack, it will require a linker script which is a major pain.
What I was thinking about is to get prelink to not map some addresses in it's cron run, because they're already used by an executable. Even if that executable is not the one being used, if it's present on the system, it should exclude our needed memory locations from being assigned by prelink.
Else, maybe mapping ourselves some memory at some different places, without using all memory between mappings, would work without actually reserving some big amount of memory/swap space. Of course, if there's a hole in the mappings and a .so is mapped right in the middle we still have a problem...
On a sidenote, I have some problems getting ldd /usr/bin/wine-{p,k]thread to run on Fedora. Anybody else have this problem (Mike?)?
Vincent
Vincent Béron vberon@mecano.gme.usherb.ca writes:
What I was thinking about is to get prelink to not map some addresses in it's cron run, because they're already used by an executable. Even if that executable is not the one being used, if it's present on the system, it should exclude our needed memory locations from being assigned by prelink.
Ah, I see what you mean. Unfortunately this doesn't solve the exec shield issue.
On Sun, 14 Dec 2003 15:30:30 -0500, Vincent Béron wrote:
Else, maybe mapping ourselves some memory at some different places, without using all memory between mappings, would work without actually reserving some big amount of memory/swap space. Of course, if there's a hole in the mappings and a .so is mapped right in the middle we still have a problem...
I think the cleanest way to solve this problem is by using linker scripts. There is a MEMORY directive we could use I think.
On a sidenote, I have some problems getting ldd /usr/bin/wine-{p,k]thread to run on Fedora. Anybody else have this problem (Mike?)?
Yes. Very strange indeed. glibc and Wine are truly mortal enemies ;)
[mike@e-ucs036 mike]$ ldd /opt/wine/bin/wine-kthread ldd: /lib/ld-linux.so.2 exited with unknown exit code (139)
thanks -mike
-
Alexandre Julliard -
Mike Hearn -
Vincent Béron