Mike McCormack mike@codeweavers.com writes:
Hi Peter,
I'm not familiar with the using "setarch i386" to solve the problem...
I've also been working on the exec-shield problem over the last couple of days. My solution is similar to Mike Hearn's approach, but faster and more compact, since it doesn't require loading of libc twice or static linking with glibc. The idea is to use a staticly linked ELF object, reserve memory and then load the target dynamicly linked object.
It seems to do what I want, but will require a patch or two to wine to use MAP_FIXED when mapping the first megabyte of address space, and to make sure newly forked processes are forked with it as the (pre)loader.
I've attached the source code. The idea is to run it like this:
wld /home/mike/wine/loader/wine-pthread my.exe
Built and tried this out.
First up, I get two instances of the following:
unknown header type 6474E551
It makes the first load work, - giving the same result as the setarch idea (I know (or at least I *think* I know) it is by a different means), but it doesn't solve the inheritance/forking problem. I assume that is what the patches you mention would do.
To make this a bit clearer, A creates children B then C. With setarch or wld when exec-shield is ON, A loads, but B doesn't. With exec-shield OFF, B loads, but C doesn't! I don't understand the latter at all.
In case it is relevant, I suspect that the child processes are created by a built-in scripting language engine.
Am open to trying out other things to get round the remaining part of this.
Peter