|
From: Yin, H. <hu...@me...> - 2005-11-01 22:01:33
|
This is seen from valgrind-3.0.1 output. The process received SIGKILL afterwards. Is this a known issue? =20 Linux bullwinkle 2.4.21-4.EL #1 Fri Oct 3 18:13:58 EDT 2003 i686 i686 i386 GNU/Linux Red Hat Enterprise Linux WS release 3 (Taroon) Thanks, --Hui =20 |
|
From: Tom H. <to...@co...> - 2005-11-01 22:04:28
|
In message <145...@sv...>
"Yin, Hui" <hu...@me...> wrote:
> This is seen from valgrind-3.0.1 output. The process received SIGKILL
> afterwards. Is this a known issue?
It should be SIGILL, not KILL...
Either way, please raise a bug for this.
Thanks,
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-11-01 22:28:23
|
On Tuesday 01 November 2005 22:04, Tom Hughes wrote: > In message > <145...@sv...> > > "Yin, Hui" <hu...@me...> wrote: > > This is seen from valgrind-3.0.1 output. The process received SIGKILL > > afterwards. Is this a known issue? > > It should be SIGILL, not KILL... > > Either way, please raise a bug for this. I'll fix it; however 66 66 90 is a pretty strange sequence. 66 is the operand size override and 90 is nop, so you have a 3-byte useless instruction. Where did you get it from? I've never seen the GNU tools generate such a thing. J |
|
From: John R.
|
> ... however 66 66 90 is a pretty strange sequence. 66 is the > operand size override and 90 is nop, so you have a 3-byte useless > instruction. It was compiled on/for x86_64, where 66 66 90 is a NOP that stalls the look-ahead instruction decoder. This is used as alignment filler after an unconditional JMP, in order to save internal CPU resources and power. It happens to run on most 32-bit x86, too. -- |
|
From: Hui <hu...@me...> - 2005-11-02 02:11:56
|
John Reiser <jreiser <at> BitWagon.com> writes: > > > ... however 66 66 90 is a pretty strange sequence. 66 is the > > operand size override and 90 is nop, so you have a 3-byte useless > > instruction. > > It was compiled on/for x86_64, where 66 66 90 is a NOP that stalls the > look-ahead instruction decoder. This is used as alignment filler after > an unconditional JMP, in order to save internal CPU resources and power. > It happens to run on most 32-bit x86, too. > The executable was compiled on/for 32-bit x86, but we actually generate this instruction directly. We generate quite a few such NOP instructions. I am a little confused why would valgrind ever work then. Does the next instruction matter here? In this case NOP is followed by a "call" instrcution (0xE8). Thanks, --Hui |
|
From: John R.
|
> The executable was compiled on/for 32-bit x86, but we actually generate this > instruction directly. We generate quite a few such NOP instructions. I am a > little confused why would valgrind ever work then. Does the next instruction > matter here? In this case NOP is followed by a "call" instrcution (0xE8). No, the next instruction (CALL in this case) does not matter. 66 66 90 is a NOP that takes the CPU 3 cycles to decode the first time (one cycle for each 66 prefix plus one cycle for the NOP) but at most 1 cycle to execute, and perhaps 0 cycles to execute on some processors. Thus it is useful after an executed JMP in order to force the decoder to slow down (some decoders don't "understand" the full meaning of unconditional JMP: the meaning is enforced by the execution unit), which saves power in contrast to what is required to decode "meaningful" instructions. Because it requires only one cycle to execute but 3 bytes to express, it may be faster than NOP NOP NOP (which might take 3 cycles to execute) while still providing alignment padding for the following instruction of a fall-through sequence. If the target of a branch is 8-byte aligned (or even cache-line aligned), then decoder efficiency often improves. The decoder only fetches 8 bytes (or whole cache lines) at a time from the icache, and must discard those bytes which preceed a branch target. -- |
|
From: Julian S. <js...@ac...> - 2005-11-03 14:13:39
|
On Tuesday 01 November 2005 22:01, Yin, Hui wrote: > This is seen from valgrind-3.0.1 output. The process received SIGKILL > afterwards. Is this a known issue? Fixed. Try this: svn co svn://svn.valgrind.org/valgrind/trunk cd trunk ./autogen.sh configure and build as usual. J |