On Sun, Sep 05, 2004 at 01:15:15PM -0400, Anish Mistry wrote: > On Sunday 29 August 2004 12:59 am, you wrote: > > On Tue, Aug 10, 2004 at 01:53:14PM -0400, Anish Mistry wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > On Wednesday 04 August 2004 06:39 pm, you wrote: > > > > On Wed, Aug 04, 2004 at 06:28:02PM -0400, Anish Mistry wrote: > > > > > Ok, so we need something like vm_map_findspace(), but for process > > > > > address mapping? ie. pmap_findspace() that will return an address to > > > > > a large enough free chunk? > > > > > > > > That's a good start, just to get something to work with. How this fits > > > > in with the vm code and whether it is ultimately suitable in the long > > > > run is probably up to Alan Cox. For now, just get something that (a) > > > > doesn't break anything else; and (b) lets Wine behave the way it needs > > > > to. > > > > > > > > AFAIK, there are still pthread issues with Wine, but those can't be > > > > addressed until the mmap issue has a work-around. > > > > > > I've got a small patch that gets by the initial problem about not being > > > to mmap the memory for the libraries, but the addresses that are mmap'ed > > > seem to seem to overlap with memory that the current pthread > > > implementation want to mmap for the "red zone" when wine tries to create > > > a thread. It can't mmap the "red zone" addresses since all those address > > > mapping where gobbled up before the thread launched. > > > I'll try to figure out a way to maybe leave a space for the "red zone" > > > and see if that works. > > > Someone who actually knows what they are doing should probably take a > > > look. > > > > The red pages are implemented by leaving the memory space unallocated; > > I don't like that one bit -- this will cause those spaces to be allocated > > but given no protection, which should provide the crash feature that the > > guard pages are there for, but be less bogus (and it doesn't use more > > "memory," but it will use a few more vm_map_entrys. > > > > Index: lib/libpthread/thread/thr_stack.c > > =================================================================== > > RCS file: /usr/ncvs/src/lib/libpthread/thread/thr_stack.c,v > > retrieving revision 1.8 > > diff -u -r1.8 thr_stack.c > > --- lib/libpthread/thread/thr_stack.c 14 Sep 2003 22:39:44 -0000 1.8 > > +++ lib/libpthread/thread/thr_stack.c 29 Aug 2004 04:50:28 -0000 > > _at__at_ -214,6 +214,17 _at__at_ > > stacksize, PROT_READ | PROT_WRITE, MAP_STACK, > > -1, 0)) == MAP_FAILED) > > attr->stackaddr_attr = NULL; > > + if (attr->stackaddr_attr != NULL) { > > + void *red; > > + > > + red = mmap((char *)attr->stackaddr_attr + stacksize, > > + _thr_guard_default, PROT_NONE, > > + MAP_ANON | MAP_FIXED | MAP_PRIVATE, -1, 0); > > + if (red == MAP_FAILED) { > > + (void)munmap(attr->stackaddr_attr, stacksize); > > + attr->stackaddr_attr = NULL; > > + } > > + } > > } > > if (attr->stackaddr_attr != NULL) > > return (0); > This is good. Can this be committed? Probably; can you verify it fixes the problem as you observe it? -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green_at_FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\Received on Sun Sep 05 2004 - 19:46:28 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:10 UTC