|
From: Nicholas N. <nj...@ca...> - 2004-07-14 17:40:32
|
Hi, I've done some more reworking of the memory layout. Log is below, and the diff is available, as is vg_main.c since the diff for it is not easy to read (things have been moved a bit), at: www.cl.cam.ac.uk/~njn25/diff.mem2 www.cl.cam.ac.uk/~njn25/vg_main.c I'd like to commit this, please let me know if there are any problems with it. It's still short of my ultimate goal of a totally flexible barrier between client and non-client memory, although it's a step in the right direction. One thing preventing me from working on that is that I currently can't work out how to move the client's stack away from 0xafffffff -- I change what look like the right values in setup_client_stack() but keep getting seg faults. Am I missing something important? Thanks. N ps: I tried sending the files as attachments, but got the "too big, waiting for moderator approval" message... so another copy of this message, with attachments, will arrive in the next day or two -- please ignore. Merged Valgrind's heap and stack. This has two main advantages: 1. It simplifies various things a bit. 2. Valgrind/tools will run out of memory later than currently in many circumstances. This is good news esp. for Calltree. Some things were going in V's 128MB, and some were going in V's 128MB map segment. Now all these things are going into a single 256MB map segment. stage2 has been moved down to 0xb0000000, the start of the 256MB map segment. The .so files needed by it are placed at 0xb1000000. This required some bootstrapping at startup for memory -- we need to allocate memory to create the segments skip-list which lets us allocate memory... solution was to make the first superblock allocated a special static one. That's pretty simple and enough to get things going. Removed vg_glibc.c which wasn't doing anything anyway. Removed VG_(brk) and associated stuff, made all the things that were calling it call VG_(mmap)() instead. Removed VG_(valgrind_mmap_end) which was no longer needed. Rejigged the startup order a bit as necessary. Moved an important comment from ume.c to vg_main.c where it should be. |
|
From: Jeremy F. <je...@go...> - 2004-07-14 20:32:30
|
On Wed, 2004-07-14 at 18:40 +0100, Nicholas Nethercote wrote: > Hi, > > I've done some more reworking of the memory layout. Log is below, and the > diff is available, as is vg_main.c since the diff for it is not easy to > read (things have been moved a bit), at: > > www.cl.cam.ac.uk/~njn25/diff.mem2 > www.cl.cam.ac.uk/~njn25/vg_main.c > > I'd like to commit this, please let me know if there are any problems with > it. Looks reasonable to me. It would be really nice to fix the constant address for info.map_base in stage1. Hm, with this arrangement, info. mapbase for stage2 is essentially where the brk used to be - after the main executable. Stage1 can work out where it is just by looking at stage2's ELF mappings. This means we could link multiple stage2's for different address space configurations, and have stage1 pick the appropriate one. > It's still short of my ultimate goal of a totally flexible barrier between > client and non-client memory, although it's a step in the right direction. > One thing preventing me from working on that is that I currently can't work out > how to move the client's stack away from 0xafffffff -- I change what look like > the right values in setup_client_stack() but keep getting seg faults. Am I > missing something important? What's segfaulting? Valgrind itself, or the client code? The client's stack location is variable anyway, so doesn't it depend on where everything else goes? Where are you trying to move it to? J |
|
From: Nicholas N. <nj...@ca...> - 2004-07-14 21:35:32
Attachments:
diff
|
On Wed, 14 Jul 2004, Jeremy Fitzhardinge wrote: > Looks reasonable to me. It would be really nice to fix the constant > address for info.map_base in stage1. Hm, with this arrangement, info. > mapbase for stage2 is essentially where the brk used to be - after the > main executable. Stage1 can work out where it is just by looking at > stage2's ELF mappings. How do you do that? Do the mappings say how big the executable is? What about stage2's stack? It has one, it's small, but system malloc() is called a few times at startup. >> It's still short of my ultimate goal of a totally flexible barrier between >> client and non-client memory, although it's a step in the right direction. >> One thing preventing me from working on that is that I currently can't work out >> how to move the client's stack away from 0xafffffff -- I change what look like >> the right values in setup_client_stack() but keep getting seg faults. Am I >> missing something important? > > What's segfaulting? Valgrind itself, or the client code? > > The client's stack location is variable anyway, so doesn't it depend on > where everything else goes? Where are you trying to move it to? I tried the attached patch (against HEAD, not my patched version) to move the stack to 0x8000000, below the main executable. Valgrind segfaults very shortly after, within setup_client_stack, during the stack copying -- at the first call to copy_str(). N |
|
From: Nicholas N. <nj...@ca...> - 2004-07-15 12:55:44
|
On Wed, 14 Jul 2004, Nicholas Nethercote wrote: >> Looks reasonable to me. It would be really nice to fix the constant >> address for info.map_base in stage1. Hm, with this arrangement, info. >> mapbase for stage2 is essentially where the brk used to be - after the >> main executable. Stage1 can work out where it is just by looking at >> stage2's ELF mappings. > > How do you do that? Do the mappings say how big the executable is? What > about stage2's stack? It has one, it's small, but system malloc() is called > a few times at startup. s/stack/heap I see the info->exe_end is set in ume.c, ume.h describes it as the "highest (allowed) address", but what does this actually mean? What about space for stage2's data? N |
|
From: Nicholas N. <nj...@ca...> - 2004-07-15 13:48:36
Attachments:
diff
|
On Wed, 14 Jul 2004, Nicholas Nethercote wrote: > I tried the attached patch (against HEAD, not my patched version) to move the > stack to 0x8000000, below the main executable. Valgrind segfaults very > shortly after, within setup_client_stack, during the stack copying -- at the > first call to copy_str(). Ok, the attached patch fixes that problem -- I wasn't moving the trampoline page along with the stack. However, with this patch, running 'date' it seg faults after 473 basic blocks: ==12099== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==12099== Access not within mapped region at address 0x7FFDFDC ==12099== at 0x1B8F50B9: __GI___fxstat64 (in /lib/ld-2.3.2.so) ==12099== by 0x1B8E9990: _dl_map_object_from_fd (in /lib/ld-2.3.2.so) ==12099== by 0x1B8E863A: _dl_map_object_internal (in /lib/ld-2.3.2.so) ==12099== by 0x1B8E6427: dl_main (in /lib/ld-2.3.2.so) I don't understand why but I guess it's something to do with the trampoline page. The address 0x7FFDFDC seems random, right in the middle of nowhere. I don't really understand what the trampoline page does so I'm a bit stuck. N |
|
From: Nicholas N. <nj...@ca...> - 2004-07-15 13:55:51
|
On Thu, 15 Jul 2004, Nicholas Nethercote wrote: > ==12099== Process terminating with default action of signal 11 (SIGSEGV): > dumping core > ==12099== Access not within mapped region at address 0x7FFDFDC > ==12099== at 0x1B8F50B9: __GI___fxstat64 (in /lib/ld-2.3.2.so) > ==12099== by 0x1B8E9990: _dl_map_object_from_fd (in /lib/ld-2.3.2.so) > ==12099== by 0x1B8E863A: _dl_map_object_internal (in /lib/ld-2.3.2.so) > ==12099== by 0x1B8E6427: dl_main (in /lib/ld-2.3.2.so) > > I don't understand why but I guess it's something to do with the trampoline > page. The address 0x7FFDFDC seems random, right in the middle of nowhere. Actually, it's just below the trampoline page... > I don't really understand what the trampoline page does so I'm a bit > stuck. N |
|
From: Nicholas N. <nj...@ca...> - 2004-07-15 14:30:58
Attachments:
diff
|
On Thu, 15 Jul 2004, Nicholas Nethercote wrote: > Actually, it's just below the trampoline page... Ok, I've worked it out. Turns out that last diff worked so long as the stack was above the client's executable. The attached diff has a fix so that it can handle the stack being below the client's executable. N |