Comment by scottdw2 | Hacker News Reader

Comment by scottdw2 | Hacker News Reader

Parent Full thread

Actually, it doesn't have to be. There are 3 forms of the interrupt instruction. 2 1 byte versions for specifying either int 3 or int 4, and a 2 byte version that can specify any interrupt number. It's possible to use either the one byte or 2 byte versions of int 3. Also, by adding arbitrary instruction prefixes (for the "int" instruction the are meaningless) it's possible to specify a breakpoint using anywhere from 1 to 15 bytes.

However, their really is no reason to use more space than necessary. If you can encode an instruction with 1 byte, it doesn't make any sense to encode it using any more bytes then what you need. Every byte that gets updated when a break point is set needs to be backed up and restored once the breakpoint is hit. Using extra bytes will hurt runtime performance.

This is particularly true given the "ptrace" interface on Linux. It only supports reading or writing a single word (2 bytes) of memory in the target process at a time. Backing up and restoring any more than 2 bytes would require extra calls into the kernel, plus extra memory barriers to ensure caches get updated. Using a scheme that did that more than once would just waste CPU cycles.

I think you missed the issue.

Consider the following code:

       jmp foo
       push ax        // 50
  foo: int 21h        // CD 21

So now we want to set a breakpoint on the "push ax". If we do it using more than a single byte, it will overwrite the int 21h instruction and the code will mess up and likely crash.

That's why 1 byte is used for breakpoints.

Why do you say a single word is 2 bytes?

On most systems, 1 byte == 8 bits, 1 word == 16 bits, 1 dword (double word) == 32 bits, etc.

This sounds like Windows terminology. I'm pretty sure on 32-bit Linux a word is 32 bits, and ptrace reads 32-bit chunks and not 16-bit chunks.

You're thinking too high-level. We're talking about a "word" in x86 instruction set parlance. It's an artifact of the old 16-bit computing days. Nothing to do with the OS.

I agree that we should't deviate from the subject too much. My reply was intended to fix the generally incorrect comment regarding the size of the word read by ptrace.

In ptrace:

> The size of a "word" is determined by the OS variant (e.g., for 32-bit Linux it's 32 bits, etc.).

Taken from http://linux.die.net/man/2/ptrace

In x86 assembly (and a lot of other contexts), 16 bits are called a word (a left over from 16 bit days when 16 bits were in fact a machine word), and larger data types are named dword (double word, 32 bits), qword (quad word, 64 bits), and so on. This terminology is even included in certain instruction mnemonics (movsb|movsw|movsd, ...).

In ptrace:

> The size of a "word" is determined by the OS variant (e.g., for 32-bit Linux it's 32 bits, etc.).

Taken from http://linux.die.net/man/2/ptrace

Reply on news.ycombinator.com