Linux 64-bit

А можно с пункта 3 объяснять попонятнее? :)

если исходный адрес равен X, то выровненный равен X & ~4095

нету 64 битного, но rip должен указывать на новую инструкцию для выполнения

если не можете проверить, зачем отвечать?
было бы все так просто, я бы не просил проверять
есть подозрение, что здесь баг

(gdb) print $rip
$1 = (void (*)()) 0x2ae225c28740 <pause+16>
(gdb) set $rip = 0x2ae225c28000
(gdb) print $rip
$2 = (void (*)()) 0x2ae225c28000 <fgetpwent_r+96>
(gdb) stepi
0x00002ae225c28000 in fgetpwent_r () from /lib/libc.so.6
(gdb) print $rip
$3 = (void (*)()) 0x2ae225c28000 <fgetpwent_r+96>
(gdb) 

(gdb) print $rip
$1 = (void (*)()) 0x2b1d1c5d4ff0 <pause+16>
(gdb) set $rip = 0x2b1d1c5d5ff0
(gdb) print $rip
$2 = (void (*)()) 0x2b1d1c5d5ff0 <setgid+16>
(gdb) stepi
0x00002b1d1c5d5ff0 in setgid () from /lib/libc.so.6
(gdb) print $rip
$3 = (void (*)()) 0x2b1d1c5d5ff0 <setgid+16>

Что-то не то с выравниванием

(gdb) print $rip
$1 = (void (*)()) 0x2b54481eeaa0 <pause+16>
(gdb) set $rip=0x2b54481ee000
(gdb) print $rip
$2 = (void (*)()) 0x2b54481ee000 <_nss_files_parse_pwent+624>

И естественно ничего не происходит

(gdb) stepi
0x00002b54481ee000 in _nss_files_parse_pwent () from /lib/libc.so.6
(gdb) print $rip
$3 = (void (*)()) 0x2b54481ee000 <_nss_files_parse_pwent+624>

дело вот в чем

(gdb) attach 3441
Attaching to process 3441
Reading symbols from /home/rei3er/bug...done.
Using host libthread_db library "/lib64/libthread_db.so.1".
Reading symbols from /lib64/libc.so.6...done.
Loaded symbols for /lib64/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
0x00002b533eabb450 in __pause_nocancel () from /lib64/libc.so.6
(gdb) set $rip = 0x2b533eabb000
(gdb) stepi
Program received signal SIGSEGV, Segmentation fault.
0x00002b533eabaffe in do_waitid () from /lib64/libc.so.6

особое внимание попрошу обратить на адрес, в do_waitid()
во-первых, произошел декремент на два, что само по себе странно
во-вторых, непонятна причина SIGSEGV, т. к по адресу 0x2b533eabb000
располагается валидная инструкция je

Я пробовал 2 раза. В первом случае так же вылетело по сегфолту, во втором - то что я написал.

Ещё раз попробовал:

(gdb) attach 7891
Attaching to process 7891
Reading symbols from /home/m1/own/c1...done.
Using host libthread_db library "/lib/libthread_db.so.1".
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux-x86-64.so.2...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
0x00002b07ca85daa0 in pause () from /lib/libc.so.6
(gdb) set $rip=0x00002b07ca85d000
(gdb) stepi
0x00002b07ca85d000 in _nss_files_parse_pwent () from /lib/libc.so.6

Я собственно, непонял с чего ты взял, что по твоему выровненному адресу вообще 
должен находиться какой-то код? Мало ли что страница 4096 байт, 
на пользовательском уровне адресное пространство линейное. 
gcc выравнивает структуры данных на границу в 16 байт.

$uname -a

Linux m1x2 2.6.22-3-amd64 #1 SMP Tue Feb 12 09:22:35 UTC 2008 x86_64 GNU/Linux

ls -l libc.so.6

lrwxrwxrwx 1 root root 11 Янв 25 00:32 libc.so.6 -> libc-2.7.so

> Я собственно, непонял с чего ты взял, что по твоему выровненному
> адресу вообще
> должен находиться какой-то код?

дизассемблер никто не отменял

процессор AMD или Intel?

AMD X2 5200+

$gcc --version
gcc (GCC) 4.2.3 (Debian 4.2.3-2)
Copyright (C) 2007 Free Software Foundation, Inc.

>по границе страницы (4096 байт)

А разве страницы на 64-х битке не по 8 Кб?

Я не помню, но автор темы использует 4096.

> А разве страницы на 64-х битке не по 8 Кб?
нет