Cleaned up some debugger stuff on ia32 and x64

Cleaned up some debugger stuff on ia32 and x64.

Got rid of the debug break on return entry code which did not add anything. It just jumped directly to the debug break on return code.

Removed the CodePatcher class on x64 as it was not implemented.

Added instruction cache flush to where the return sequence was patched on x64.

Added some missing ENABLE_DEBUGGER_SUPPORT #ifdef/#endif.

Committed: http://code.google.com/p/v8/source/detail?r=2863

[Lasse Reichstein, 2009-09-09 14:26:20]

LGTM

http://codereview.chromium.org/193057/diff/1/2
File src/debug.h (right):

http://codereview.chromium.org/193057/diff/1/2#newcode338
Line 338: // Access to the debug break on return return code.
"return return" -> "return"?

http://codereview.chromium.org/193057/diff/1/8
File src/x64/assembler-x64.cc (right):

http://codereview.chromium.org/193057/diff/1/8#newcode181
Line 181: // the 0x00 later, and this lets us write a uint32.
So we really write three bytes. The low byte is only there because we know that
the byte before will be written again later (and it doesn't matter that it's
zero).
Comment isn't very clear.

http://codereview.chromium.org/193057/diff/1/8#newcode182
Line 182: Memory::uint32_at(patch_site + 9) = 0xD2FF4900u;  // 0x00, call r10
Ick, can't we use a patcher to emit opcodes, instead of raw binary numbers?

[Søren Thygesen Gjesse, 2009-09-09 17:44:33]

http://codereview.chromium.org/193057/diff/1/2
File src/debug.h (right):

http://codereview.chromium.org/193057/diff/1/2#newcode338
Line 338: // Access to the debug break on return return code.
On 2009/09/09 14:26:20, Lasse Reichstein wrote:
> "return return" -> "return"?

Done.

http://codereview.chromium.org/193057/diff/1/8
File src/x64/assembler-x64.cc (right):

http://codereview.chromium.org/193057/diff/1/8#newcode181
Line 181: // the 0x00 later, and this lets us write a uint32.
On 2009/09/09 14:26:20, Lasse Reichstein wrote:
> So we really write three bytes. The low byte is only there because we know
that
> the byte before will be written again later (and it doesn't matter that it's
> zero).
> Comment isn't very clear.

I will leave this as is, and add the code patcher in a separate changelist. The
reason I pulled it out of the macro-assembler-x64.h file was that it was not
implemented.

http://codereview.chromium.org/193057/diff/1/8#newcode182
Line 182: Memory::uint32_at(patch_site + 9) = 0xD2FF4900u;  // 0x00, call r10
On 2009/09/09 14:26:20, Lasse Reichstein wrote:
> Ick, can't we use a patcher to emit opcodes, instead of raw binary numbers?

See above.