по мотивам этой темы
господа обладатели 64-х битных систем (AMD64, EM64T)
прошу провести следующий эксперимент
1. пишем программу

2. запускаем ее
3. через ps определяем PID процесса
4. запускаем gdb
5. подключаемся к процессу

и оказываемся где-то в __nanosleep_nocancel()
6. выравниваем текущий RIP по размеру страницы в меньшую сторону (допустим текущий RIP = 0x2acb0d2ba4c0, тогда выровненное значение = 0x2acb0d2ba000) и запоминаем выровненное значение

7. делаем stepi

и смотрим текущий RIP
он меньше исходного на 1  (по крайней мере у меня)
у кого такие же результаты?
C2D, 1.86Ghz, kernel 2.6.18 (64-bit) 

Это сообщение отредактировал(а) MAKCim - 21.2.2008, 18:20

я не верю, что ни у кого нет 64-х битного процессора с установленным Linux   

MAKCim, вот он я   Сейчас попробую повторить...

Добавлено через 7 минут и 46 секунд

JackYF, 
у тебя то же самое
я не могу это объяснить   

Ну, у меня получается, что он меньше исходного на двойку.
Подожди, а что ты хочешь получить, выполняя инструкцию по адресу, выровненному по странице?

не важно, главное, что меньше


либо тот же адрес (если возникает #UD из-за того, что по выровненному адресу нет валидной инструкции), либо адрес на N больше (N - размер в байтах инструкции по выровненному адресу)

извиняюсь за некомпетентность... 

rip - это IP ( instruction pointer ) ? 

если ты уменьшил его значение на так сильно, т.е. с 0x2acb0d2ba4c0 -> 0x2acb0d2b0000
а потом продвинул, то почему удивляет что он еще "сзади" ?

пожалуйста разжуй, может в процессе и сам найдешь ответ на свой вопрос 

что он после этого пошёл ещё назад, а не вперёд.

нет
RIP - это RIP   
но смысл такой же, как и у IP

RIP никогда не уменьшается при линейном выполнении кода без переполнения

у тебя в коде есть цикл...

какое отношение цикл в коде имеет к тому, что я сказал?   

еще раз поясню ситуацию
в цикле вызывается sleep() продолжительностью 10 секунд
GDB подсоединяется к процессу в то время, когда он находится в режиме ядра в состоянии TASK_INTERRUPTIBLE в ожидании события таймера
GDB останавливает процесс
далее мы изменяем RIP (GDB использует ptrace(PTRACE_SETREGS, ...)), при этом новое значение RIP записывается в стек ядра процесса, откуда оно будет восстановлено при возврате процесса из функции sys_nanosleep() (sleep() разворачивается в вызов системного сервиса sys_nanosleep())
далее мы выполняем stepi (GDB использует ptrace(PTRACE_SINGLESTEP, ...))
реализация ptrace() в ядре (sys_ptrace()) вызывает wake_up_process() для трассируемого процесса, что приводит к добавлению его в одну из очередей выполнения, далее изменяет состояние процесса на TASK_RUNNING и устанавливает бит TF в образе RFLAGS в стеке ядра (RFLAGS, как и RIP, восстанавливается при возврате из режима ядра)
через некоторое время планировщик процессов выбирает этот процесс и запускает его
после получения управления процесс осуществляет возврат из sys_nanosleep() (потому как 10 секунд на текущей итерации уже давно прошли), при этом восстанавливаются новые значения RIP и RFLAGS
дальше по идее, должно идти выполнение одной инструкции по новому адресу с инкрементацией RIP
здесь возможно два случая
либо генерация #UD (если инструкция по новому адресу не валидна), либо, собственно, выполнение инструкции, генерация #DB, остановка процесса, передача управления GDB
однако ничего подобного не происходит и RIP декрементируется

http://cygwin.com/ml/systemtap/2005-q1/txt00002.txt

bilbobagginz, 
какое отношение к моей проблеме имеет описанная в ссылке проблема?

короче, буду я, наверное, bug-report писАть
во всяком случае, хотя бы ответ получу, баг это или нет

MAKCim, можно и в рассылке поговорить с людьми  Или выловить в IRC.