|
From: Jeremy F. <je...@go...> - 2005-01-25 23:21:19
|
On Tue, 2005-01-25 at 12:32 -0800, Naveen Kumar wrote: > Hi all, > I have finally got to the stage where the following > commands > > valgrind > valgrind --help > valgrind --tool=xxxxx > valgrind --tool=xxxxx --help > > work. Some items of note. I am using the following > address space mapping > > client_base 9000000 (498MB) > client_mapbase 28280000 (998MB) > client_end 66900000 (1MB) > shadow_base 66A00000 (1684MB) > shadow_end CFE20000 (1MB) > valgrind_base D0000000 (255MB) > valgrind_end DFFFFFFF > > since the stack is positioned below the text > segment(for sol-x86) the whole space above text until > kernelbase can be used. kernelbase has been #defined > to 0xE0000000. CLIENT_BASE starts from 0x09000000 > instead of 0x00000000 as in Linux-x86. In > layout_remaining_space Why start at 0x9000000? client_base is the base of the client address space, so it has to include the client stack. Setting client_base to 0x9000000 implies that it is absolutely forbidden, under any circumstances, for the client to touch memory in the range 0x0-0x9000000. > client_size should include VG_(valgrind_base) and > VG_(client_base) in the calculation. > > client_size = ROUNDDN((VG_(valgrind_base)- > REDZONE_SIZE-VG_(client_base)) / (1.+ratio), > CLIENT_SIZE_MULTIPLE); > > Am I correct is doing that ? Well, if the range 0-client_base off limits for client use, then probably. > Another interesting note. When doing a fillgap from > 0x08a00000(text seg end) to 0xD0000000(kickstart_base) > the mmap call failed with err ENOSPC. However if you > split the region into chunks and do an mmap it > works!!!. I dont know why. This is weird. Currently I > break it up into 0x40000000 size chunks. > This was one tough err to track down. Yeah, some Linux kernels with some configurations do that too, though normally its OK because those mappings are mapped out of a file. The kernel is applying a heuristic to prevent your process from using "too much" memory, by trying to guess how much the process will end up using by looking at the address space it claims. Since we never intend to use that memory at all, its estimates are off. > The problem I am currently having is that when > executing in stage2, the program crashes at fprintf(or > printf) in load_ELF(ume.c). A printf in vg_main.c > shows no problems but a printf at any point in > load_ELF gives a seg fault. Any ideas ??? Is it just printf, or any libc function? Is memory padded at the time? Could it be something trying to allocate and failing? What's the fault address? J |