Про адресное пространство.
Сегодня игрался с gdb и обнаружил интересную вещицу. Я запустил 2 экземпляра gdb с одним и тем же исполняемым файлом (назовем его - test). Дизассемблировал функцию main(), и обнаружил, что адреса в обоих экземплярах gdb - совпадают. Походу, я что-то не так понимаю. Я полагал, что когда я запускаю процесс - ему выделяется свое адресное пространство. И таким образом, если я запущу два экземпляра программы 'test', адрес функции main первого экземпляра должен отличаться от адреса одноименной функции второго экземпляра, т.к. они находятся в разных адресных пространствах. Судя по всему, что-то из этого работает не так, как мне казалось. Вот я и хотел бы узнать у знающих людей, что именно. -- ** * jabber: free...@jabber.mipt.ru * * Registered linux user #546240* **
Re: Про адресное пространство.
On 2013.01.10 at 13:22:42 +0400, Dmitrii Kashin wrote: Сегодня игрался с gdb и обнаружил интересную вещицу. Я запустил 2 экземпляра gdb с одним и тем же исполняемым файлом (назовем его - test). Дизассемблировал функцию main(), и обнаружил, что адреса в обоих экземплярах gdb - совпадают. Походу, я что-то не так понимаю. Я полагал, что когда я запускаю процесс - ему выделяется свое адресное пространство. И таким образом, если я запущу два экземпляра программы 'test', адрес функции main первого экземпляра должен отличаться от адреса одноименной функции второго экземпляра, т.к. они находятся в разных адресных пространствах. Именно потому, что каждой программе выделяется своё адресное пространство, адреса имеют полное право совпадать. Вот если бы два экземпляра программы были загружены в одно адресное пространство, то пришлось бы одним и тем же объектам разных экземпляров располагаться по разным адресам. А так, имеем в распоряжении два одинаковых адресных пространства. С адресами от 0 до 4 миллиардов. Грузим туда одинаковым загрузчиком одинаковые исполняемые образы. Естественно, что результат получается одинаковый. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130110093541.ga15...@wagner.pp.ru
Re: Про адресное пространство.
On Thu, 10 Jan 2013, Dmitrii Kashin wrote: Сегодня игрался с gdb и обнаружил интересную вещицу. Я запустил 2 экземпляра gdb с одним и тем же исполняемым файлом (назовем его - test). Дизассемблировал функцию main(), и обнаружил, что адреса в обоих экземплярах gdb - совпадают. Походу, я что-то не так понимаю. Я полагал, что когда я запускаю процесс - ему выделяется свое адресное пространство. И таким образом, если я запущу два экземпляра программы 'test', адрес функции main первого экземпляра должен отличаться от адреса одноименной функции второго экземпляра, т.к. они находятся в разных адресных пространствах. Судя по всему, что-то из этого работает не так, как мне казалось. Вот я и хотел бы узнать у знающих людей, что именно. Посмотрите здесь http://www.ualberta.ca/CNS/RESEARCH/LinuxClusters/mem.html Ю.
Re: Про адресное пространство.
Victor Wagner vi...@wagner.pp.ru writes: On 2013.01.10 at 13:22:42 +0400, Dmitrii Kashin wrote: Сегодня игрался с gdb и обнаружил интересную вещицу. Я запустил 2 экземпляра gdb с одним и тем же исполняемым файлом (назовем его - test). Дизассемблировал функцию main(), и обнаружил, что адреса в обоих экземплярах gdb - совпадают. Походу, я что-то не так понимаю. Я полагал, что когда я запускаю процесс - ему выделяется свое адресное пространство. И таким образом, если я запущу два экземпляра программы 'test', адрес функции main первого экземпляра должен отличаться от адреса одноименной функции второго экземпляра, т.к. они находятся в разных адресных пространствах. Именно потому, что каждой программе выделяется своё адресное пространство, адреса имеют полное право совпадать. Вот если бы два экземпляра программы были загружены в одно адресное пространство, то пришлось бы одним и тем же объектам разных экземпляров располагаться по разным адресам. В том-то все и дело, что, как мне кажется, совпадают именно физические адреса. Вот конкретный пример: (gdb) disassemble main Dump of assembler code for function main: 0x080483dc +0:push %ebp 0x080483dd +1:mov%esp,%ebp 0x080483df +3:sub$0x10,%esp 0x080483e2 +6:movl $0x0,-0x4(%ebp) 0x080483e9 +13: movl $0x3,-0x4(%ebp) 0x080483f0 +20: mov$0x0,%eax 0x080483f5 +25: leave 0x080483f6 +26: ret End of assembler dump. Я посчитал, что 0x0800 - это 128 MiB. Мне сдается, что это адрес физической памяти, а не виртуальной. Но именно эти адреса совпадают. И если я запускаю второй gdb - я увижу тот же 0x080483dc. Почему - не понятно. Может быть, это какой-то префикс, и мна первые две цифры адреса мне смотреть не надо? -- ** * jabber: free...@jabber.mipt.ru * * Registered linux user #546240* ** -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d2xdqs0t@ws00.freehck.ru
Re: Про адресное пространство.
Эти адреса никак не могут относиться к физической памяти. 10.01.2013, 13:58, Dmitrii Kashin free...@gmail.com: Victor Wagner vi...@wagner.pp.ru writes: On 2013.01.10 at 13:22:42 +0400, Dmitrii Kashin wrote: Сегодня игрался с gdb и обнаружил интересную вещицу. Я запустил 2 экземпляра gdb с одним и тем же исполняемым файлом (назовем его - test). Дизассемблировал функцию main(), и обнаружил, что адреса в обоих экземплярах gdb - совпадают. Походу, я что-то не так понимаю. Я полагал, что когда я запускаю процесс - ему выделяется свое адресное пространство. И таким образом, если я запущу два экземпляра программы 'test', адрес функции main первого экземпляра должен отличаться от адреса одноименной функции второго экземпляра, т.к. они находятся в разных адресных пространствах. Именно потому, что каждой программе выделяется своё адресное пространство, адреса имеют полное право совпадать. Вот если бы два экземпляра программы были загружены в одно адресное пространство, то пришлось бы одним и тем же объектам разных экземпляров располагаться по разным адресам. В том-то все и дело, что, как мне кажется, совпадают именно физические адреса. Вот конкретный пример: (gdb) disassemble main Dump of assembler code for function main: 0x080483dc +0: push %ebp 0x080483dd +1: mov %esp,%ebp 0x080483df +3: sub $0x10,%esp 0x080483e2 +6: movl $0x0,-0x4(%ebp) 0x080483e9 +13: movl $0x3,-0x4(%ebp) 0x080483f0 +20: mov $0x0,%eax 0x080483f5 +25: leave 0x080483f6 +26: ret End of assembler dump. Я посчитал, что 0x0800 - это 128 MiB. Мне сдается, что это адрес физической памяти, а не виртуальной. Но именно эти адреса совпадают. И если я запускаю второй gdb - я увижу тот же 0x080483dc. Почему - не понятно. Может быть, это какой-то префикс, и мна первые две цифры адреса мне смотреть не надо? -- ** * jabber: free...@jabber.mipt.ru * * Registered linux user #546240 * ** -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d2xdqs0t@ws00.freehck.ru -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/631441357812...@web8h.yandex.ru
Re: Про адресное пространство.
On Thu, Jan 10, 2013 at 01:35:41PM +0400, Victor Wagner wrote: А так, имеем в распоряжении два одинаковых адресных пространства. С адресами от 0 до 4 миллиардов. Грузим туда одинаковым загрузчиком одинаковые исполняемые образы. Естественно, что результат получается одинаковый. Нынче это не совсем естественно, из-за рандомизации адресов загрузки: % date ; ldd /bin/date ; date ; ldd /bin/date Чтв Янв 10 14:00:43 MSK 2013 linux-gate.so.1 = (0xb772d000) librt.so.1 = /lib/i386-linux-gnu/i686/cmov/librt.so.1 (0xb7712000) libc.so.6 = /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb75af000) libpthread.so.0 = /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 (0xb7596000) /lib/ld-linux.so.2 (0xb772e000) Чтв Янв 10 14:00:43 MSK 2013 linux-gate.so.1 = (0xb77cc000) librt.so.1 = /lib/i386-linux-gnu/i686/cmov/librt.so.1 (0xb77b1000) libc.so.6 = /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb764e000) libpthread.so.0 = /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 (0xb7635000) /lib/ld-linux.so.2 (0xb77cd000) Конечно, под дебаггером загрузка может иметь существенные отличия, и есть нюансы (в том числе возможность отключить рандомизацию), но сегодня в линуксе на постоянные адреса рассчитывать не следует. -- Eugene Berdnikov -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130110100735.gk27...@protva.ru
Re: Про адресное пространство.
Hi, Eugene! EB == Eugene Berdnikov writes: On Thu, Jan 10, 2013 at 01:35:41PM +0400, Victor Wagner wrote: А так, имеем в распоряжении два одинаковых адресных пространства. С адресами от 0 до 4 миллиардов. Грузим туда одинаковым загрузчиком одинаковые исполняемые образы. Естественно, что результат получается одинаковый. Нынче это не совсем естественно, из-за рандомизации адресов загрузки: % date ; ldd /bin/date ; date ; ldd /bin/date Ну библиотеки-то PIC, фиг с ними. -- WBR, Yauheni Kaliuta -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87a9sh1ddv@home.kaliuta.org
Re: Про адресное пространство.
10.01.2013 13:22, Dmitrii Kashin пишет: Сегодня игрался с gdb и обнаружил интересную вещицу. Я запустил 2 экземпляра gdb с одним и тем же исполняемым файлом (назовем его - test). Дизассемблировал функцию main(), и обнаружил, что адреса в обоих экземплярах gdb - совпадают. Походу, я что-то не так понимаю. Я полагал, что когда я запускаю процесс - ему выделяется свое адресное пространство. И таким образом, если я запущу два экземпляра программы 'test', адрес функции main первого экземпляра должен отличаться от адреса одноименной функции второго экземпляра, т.к. они находятся в разных адресных пространствах. Судя по всему, что-то из этого работает не так, как мне казалось. Вот я и хотел бы узнать у знающих людей, что именно. Прочтите что нибудь на тему защищенного режима. Хоть в той же википедии. Если коротко - адреса программы в непривилегированном режиме не обязаны совпадать с адресами физической памяти. Благодаря этому, в частности, программа может выделить себе больше памяти чем есть физически и адресоваться к ней. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50eeadf7.40...@mail.ru
Re: Сломался hibernate
On Thu, Jan 10, 2013 at 10:50:03PM +0400, Сергей Москвичёв wrote: Доброго времени суток! Отправляю ноутбук в спящий (suspend-to-disk) режим. Засыпает. Нажимаю кнопку power - грузится как после hard reset. С переходом в ждущий (suspend-to-ram) и выходом из него проблем нет. Поломалось после подвижки разделов. Сейчас размеры таковы Device Boot Start End Blocks Id System /dev/sda12048 4401151 2199552 82 Linux swap / Solaris /dev/sda2 * 44011524634214320970496 83 Linux /dev/sda346342144 625141759 289399808 83 Linux Ну так посмотрите, что в resume=, и напишите туда правильное значение. А вообще вы зря dmesg не читали. -- WBR, wRAR signature.asc Description: Digital signature
Re: Про адресное пространство.
On Thu, Jan 10, 2013 at 01:22:42PM +0400, Dmitrii Kashin wrote: Сегодня игрался с gdb и обнаружил интересную вещицу. Я запустил 2 экземпляра gdb с одним и тем же исполняемым файлом (назовем его - test). Дизассемблировал функцию main(), и обнаружил, что адреса в обоих экземплярах gdb - совпадают. Походу, я что-то не так понимаю. Я полагал, что когда я запускаю процесс - ему выделяется свое адресное пространство. И таким образом, если я запущу два экземпляра программы 'test', адрес функции main первого экземпляра должен отличаться от адреса одноименной функции второго экземпляра, т.к. они находятся в разных адресных пространствах. Судя по всему, что-то из этого работает не так, как мне казалось. Вот я и хотел бы узнать у знающих людей, что именно. Это конечно старая книжка. Описано по ядру 2.0 http://www.tldp.org/LDP/tlk/tlk.html Про виртуальную память вот тут http://www.tldp.org/LDP/tlk/mm/memory.html -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130110182153.ga26...@intex.spb.ru
Re: Сломался hibernate
On Fri, Jan 11, 2013 at 12:47:06AM +0400, Сергей Москвичёв wrote: Ну так посмотрите, что в resume=, и напишите туда правильное значение. А вообще вы зря dmesg не читали. Ваш ответ не очень изобилует конкретикой. Я подразумевал, что для того, чтобы заработало просыпание, вы вписывали resume= и должны понимать, о чём речь и как это работает. Я не в курсе, может ли и если да, то каким образом, дефолтное ядро находить устройство для просыпания само. Да простят меня подписчики, далее вывод dmesg, но что там указывает на мою проблему мне не понятно. [1.425973] PM: Hibernation image not present or could not be loaded. -- WBR, wRAR signature.asc Description: Digital signature
Re: Сломался hibernate
В Птн, 11/01/2013 в 02:56 +0600, Andrey Rahmatullin пишет: Я подразумевал, что для того, чтобы заработало просыпание, вы вписывали resume= и должны понимать, о чём речь и как это работает. Я не в курсе, может ли и если да, то каким образом, дефолтное ядро находить устройство для просыпания само. поток сознания... -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1357852746.1991.4.camel@skynet
Re: Сломался hibernate
Я подразумевал, что для того, чтобы заработало просыпание, вы вписывали resume= и должны понимать, о чём речь и как это работает. Я не в курсе, может ли и если да, то каким образом, дефолтное ядро находить устройство для просыпания само. Просто поставил пакет pm-utils. Руками ничего не правил, т.к. всё заработало как надо. Да простят меня подписчики, далее вывод dmesg, но что там указывает на мою проблему мне не понятно. [1.425973] PM: Hibernation image not present or could not be loaded. Я искал по словам error и boot. -- С уважением, Сергей Москвичёв. xmpp: uks...@ya.ru
Re: Сломался hibernate
On Fri, Jan 11, 2013 at 01:41:14AM +0400, Сергей Москвичёв wrote: Я подразумевал, что для того, чтобы заработало просыпание, вы вписывали resume= и должны понимать, о чём речь и как это работает. Я не в курсе, может ли и если да, то каким образом, дефолтное ядро находить устройство для просыпания само. Просто поставил пакет pm-utils. Руками ничего не правил, т.к. всё заработало как надо. А uswsusp? uswsusp умеет просыпаться из initramfs, но для этого, конечно, в initramfs должен лежать конфиг с акутальным именем устройства с образом. Если у вас используется именно это, делайте dpkg-reconfigure uswsusp Да простят меня подписчики, далее вывод dmesg, но что там указывает на мою проблему мне не понятно. [1.425973] PM: Hibernation image not present or could not be loaded. Я искал по словам error и boot. Искать в dmesg глупо, когда не знаете точно, что искать. -- WBR, wRAR signature.asc Description: Digital signature
Re: Сломался hibernate
А uswsusp?
uswsusp умеет просыпаться из initramfs, но для этого, конечно, в initramfs
должен лежать конфиг с акутальным именем устройства с образом. Если у вас
используется именно это, делайте dpkg-reconfigure uswsusp
этот пакет у меня не установлен.
Я искал по словам error и boot.
Искать в dmesg глупо, когда не знаете точно, что искать.
Не поспоришь.
Поискал ещё и на внезапно на http://wiki.debian.org/Grub#FAQ нашёл следующее
By default grub2 in debian will not add 'resume=/dev/swap-partition' option.
But if you want to perform this by default you can edit
/etc/grub.d/10_linux file and make some changes there:
Replace
linux ${rel_dirname}/${basename} root=${linux_root_device_thisversion} ro
${args}
with this
linux ${rel_dirname}/${basename} root=${linux_root_device_thisversion} ro
${args} resume=`swapon -s | grep '/dev/sd.[0-9]' -o`
This will add your first swap partition to all found linux entries.
Проделал и проблема решилась. Как раньше просыпание происходило без этого
параметра - загадка для меня. Спасибо за ключевое слово resume=.
--
С уважением, Сергей Москвичёв.
xmpp: uks...@ya.ru
[RFR] wml://...
Очередная порция патчей к русским переводам (rus.patch) и несколько новых переводов (en_ru.patch). Cheers! Lev Lamberov devel_wnpp_index.wml.rus.patch Description: Binary data mirror_submit.wml.rus.patch Description: Binary data partners_index.wml.rus.patch Description: Binary data ports_arm_index.wml.rus.patch Description: Binary data ports_arm_links.wml.en_ru.patch Description: Binary data ports_m68k_links.wml.en_ru.patch Description: Binary data ports_m68k_index.wml.rus.patch Description: Binary data
[RFR] wml://women/
Cheers! Lev Lamberov women_faq.wml.en_ru.patch Description: Binary data women_index.wml.en_ru.patch Description: Binary data women_mentoring.wml.en_ru.patch Description: Binary data women_participate.wml.en_ru.patch Description: Binary data women_profiles_index.wml.en_ru.patch Description: Binary data women_contact.wml.en_ru.patch Description: Binary data women_about.wml.en_ru.patch Description: Binary data
