|
From: Todd J. <qua...@gm...> - 2010-08-24 06:19:46
|
Hello all, I'm working on my own tool for Valgrind and have a few questions on how it handles stack movement: Backround: I have test programs that contain instructions that shift the stack pointer between 4 and 6 MB down (eg. leal $-4243104(%esp), %esp) at the beginning of the program. This causes Valgrind to receive a signal 11, manipulate the stack, and then restart the instruction that caused the signal. Valgrind tells me that it thinks that the client has switched stacks and to use --max-stackframe=6291452. I have tried --main-stacksize and the given --max-stackframe option to suppress the signal to no avail. Valgrind runs fine - I just want to avoid this signal 11. From the comments in Valgrind it seems like the signal is caused by the program exceeding some kind of stack limit, but I'm not sure where. The test programs work find outside of Valgrind. Questions: Is there a better way of preventing this signal 11 from the command line? Where in Valgrind does it set the stack that the client program uses and the memory block that sets up the client's stack? Thanks! |
|
From: Tom H. <to...@co...> - 2010-08-24 07:42:59
|
On 24/08/10 07:19, Todd Jackson wrote: > Backround: I have test programs that contain instructions that shift the stack pointer between 4 and 6 MB down (eg. leal $-4243104(%esp), %esp) at the beginning of the program. This causes Valgrind to receive a signal 11, manipulate the stack, and then restart the instruction that caused the signal. Valgrind tells me that it thinks that the client has switched stacks and to use --max-stackframe=6291452. I have tried --main-stacksize and the given --max-stackframe option to suppress the signal to no avail. Valgrind runs fine - I just want to avoid this signal 11. From the comments in Valgrind it seems like the signal is caused by the program exceeding some kind of stack limit, but I'm not sure where. Why do you want to stop the signal 11 though? It's entirely normal and is how the stack gets extended in all programs. The only difference is that normally the fault is handled by the kernel, which extends the stack and restarts the program, and here valgrind is acting as the supervisor and catching the fault and performing the stack extension. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Todd J. <qua...@gm...> - 2010-08-24 17:00:22
|
On Aug 24, 2010, at 12:42 AM, Tom Hughes wrote: > On 24/08/10 07:19, Todd Jackson wrote: > >> Backround: I have test programs that contain instructions that shift the stack pointer between 4 and 6 MB down (eg. leal $-4243104(%esp), %esp) at the beginning of the program. This causes Valgrind to receive a signal 11, manipulate the stack, and then restart the instruction that caused the signal. Valgrind tells me that it thinks that the client has switched stacks and to use --max-stackframe=6291452. I have tried --main-stacksize and the given --max-stackframe option to suppress the signal to no avail. Valgrind runs fine - I just want to avoid this signal 11. From the comments in Valgrind it seems like the signal is caused by the program exceeding some kind of stack limit, but I'm not sure where. > > Why do you want to stop the signal 11 though? It's entirely normal and is how the stack gets extended in all programs. > > The only difference is that normally the fault is handled by the kernel, which extends the stack and restarts the program, and here valgrind is acting as the supervisor and catching the fault and performing the stack extension. > Valgrind is running under a process monitor. The monitor is getting confused by the signal 11, because the monitor watches at least two versions (same source code, different binary) the same program at the same time to make sure they're doing the same thing. I see the signal 11 in one version and not the other, which is why I want to prevent the signal 11. I think I can get around it by rearranging the guest's stack pointer at start up so that the shift doesn't cause the signal 11 and subsequent stack extension, but I can't find the stack initialization code in Valgrind. Todd |