* [devel] libc on i586: WTF? @ 2010-10-16 4:26 REAL 2010-10-16 11:18 ` Dmitry V. Levin 2010-10-16 11:40 ` Sergey Vlasov 0 siblings, 2 replies; 8+ messages in thread From: REAL @ 2010-10-16 4:26 UTC (permalink / raw) To: ALT Linux Team development discussions Привет! Что-то загадочное произошло на вчерашнем срезе сизифа (может быть и раньше так было, только не замечал): $ gfortran -O2 -c ilaenv.f $ nm ilaenv.o|grep stack_chk_fail U __stack_chk_fail НО: $ gfortran -fPIC -O2 -c ilaenv.f $ nm ilaenv.o|grep stack_chk_fail U __stack_chk_fail_local Проявляется на i586, на x86_64 всё в порядке. Символ __stack_chk_fail_local присутствует только в libc.a, не в libc.so: $ nm /usr/lib/libc.a|grep stack_chk_fail stack_chk_fail.o: 0000000000000000 T __stack_chk_fail stack_chk_fail_local.o: U __stack_chk_fail 0000000000000000 T __stack_chk_fail_local $ nm -D /lib/libc.so.6|grep stack_chk_fail 00000000000e09a0 T __stack_chk_fail Как дальше жидь? -- REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [devel] libc on i586: WTF? 2010-10-16 4:26 [devel] libc on i586: WTF? REAL @ 2010-10-16 11:18 ` Dmitry V. Levin 2010-10-18 3:32 ` REAL 2010-10-16 11:40 ` Sergey Vlasov 1 sibling, 1 reply; 8+ messages in thread From: Dmitry V. Levin @ 2010-10-16 11:18 UTC (permalink / raw) To: ALT Linux Team development discussions [-- Attachment #1: Type: text/plain, Size: 1438 bytes --] Hi, On Sat, Oct 16, 2010 at 12:26:18PM +0800, REAL wrote: > > Что-то загадочное произошло на вчерашнем > срезе сизифа (может быть и раньше так > было, только не замечал): > > $ gfortran -O2 -c ilaenv.f > $ nm ilaenv.o|grep stack_chk_fail > U __stack_chk_fail > > НО: > $ gfortran -fPIC -O2 -c ilaenv.f > $ nm ilaenv.o|grep stack_chk_fail > U __stack_chk_fail_local > > Проявляется на i586, на x86_64 всё в порядке. Так было всегда, на i586 маловато регистров. <cite> > Этому [text relocations в shared objects] нет оправдания. Есть. На дебильных x86 это дикий оверхед. Один регистр общего назначения - коту под хвост. При том, что их на этом калькуляторе-переростке и так не богато. -- vsl in devel@ </cite> > Символ __stack_chk_fail_local присутствует только > в libc.a, не в libc.so: > > $ nm /usr/lib/libc.a|grep stack_chk_fail > stack_chk_fail.o: > 0000000000000000 T __stack_chk_fail > stack_chk_fail_local.o: > U __stack_chk_fail > 0000000000000000 T __stack_chk_fail_local > > $ nm -D /lib/libc.so.6|grep stack_chk_fail > 00000000000e09a0 T __stack_chk_fail > > Как дальше жидь? Вам просто интересно, или беспокойство чем-то обусловлено? В первом случае см. http://sourceware.org/git/?p=glibc.git;a=blob;f=debug/stack_chk_fail_local.c Во втором случае просто выкиньте это из головы. -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [devel] libc on i586: WTF? 2010-10-16 11:18 ` Dmitry V. Levin @ 2010-10-18 3:32 ` REAL 2010-10-18 8:19 ` Dmitry V. Levin 0 siblings, 1 reply; 8+ messages in thread From: REAL @ 2010-10-18 3:32 UTC (permalink / raw) To: ALT Linux Team development discussions Dmitry V. Levin пишет: >> Символ __stack_chk_fail_local присутствует только >> в libc.a, не в libc.so: >> >> $ nm /usr/lib/libc.a|grep stack_chk_fail >> stack_chk_fail.o: >> 0000000000000000 T __stack_chk_fail >> stack_chk_fail_local.o: >> U __stack_chk_fail >> 0000000000000000 T __stack_chk_fail_local >> >> $ nm -D /lib/libc.so.6|grep stack_chk_fail >> 00000000000e09a0 T __stack_chk_fail >> >> Как дальше жидь? > > Вам просто интересно, или беспокойство чем-то обусловлено? Скажем так: мне интересно, зачем я должен при сборке shared библиотек использовать libc.a. > В первом случае см. > http://sourceware.org/git/?p=glibc.git;a=blob;f=debug/stack_chk_fail_local.c Может быть, вместо libc.a заюзать объект, полученный через ar x %_libdir/libc.a stack_chk_fail_local.o? -- REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [devel] libc on i586: WTF? 2010-10-18 3:32 ` REAL @ 2010-10-18 8:19 ` Dmitry V. Levin 0 siblings, 0 replies; 8+ messages in thread From: Dmitry V. Levin @ 2010-10-18 8:19 UTC (permalink / raw) To: ALT Linux Team development discussions [-- Attachment #1: Type: text/plain, Size: 1036 bytes --] On Mon, Oct 18, 2010 at 11:32:30AM +0800, REAL wrote: > Dmitry V. Levin пишет: > >>Символ __stack_chk_fail_local присутствует только > >>в libc.a, не в libc.so: > >> > >>$ nm /usr/lib/libc.a|grep stack_chk_fail > >>stack_chk_fail.o: > >>0000000000000000 T __stack_chk_fail > >>stack_chk_fail_local.o: > >> U __stack_chk_fail > >>0000000000000000 T __stack_chk_fail_local > >> > >>$ nm -D /lib/libc.so.6|grep stack_chk_fail > >>00000000000e09a0 T __stack_chk_fail > >> > >>Как дальше жидь? > > > >Вам просто интересно, или беспокойство > >чем-то обусловлено? > > Скажем так: мне интересно, зачем я должен > при сборке shared библиотек использовать > libc.a. Этот символ есть в libc_nonshared.a, так что -lc будет достаточно. > >В первом случае см. > >http://sourceware.org/git/?p=glibc.git;a=blob;f=debug/stack_chk_fail_local.c > > Может быть, вместо libc.a заюзать объект, > полученный через ar x %_libdir/libc.a stack_chk_fail_local.o? В этом нет необходимости. -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [devel] libc on i586: WTF? 2010-10-16 4:26 [devel] libc on i586: WTF? REAL 2010-10-16 11:18 ` Dmitry V. Levin @ 2010-10-16 11:40 ` Sergey Vlasov 2010-10-18 3:37 ` REAL 1 sibling, 1 reply; 8+ messages in thread From: Sergey Vlasov @ 2010-10-16 11:40 UTC (permalink / raw) To: devel [-- Attachment #1: Type: text/plain, Size: 2211 bytes --] On Sat, Oct 16, 2010 at 12:26:18PM +0800, REAL wrote: > Что-то загадочное произошло на вчерашнем срезе сизифа (может быть и > раньше так было, только не замечал): > > $ gfortran -O2 -c ilaenv.f > $ nm ilaenv.o|grep stack_chk_fail > U __stack_chk_fail > > НО: > $ gfortran -fPIC -O2 -c ilaenv.f > $ nm ilaenv.o|grep stack_chk_fail > U __stack_chk_fail_local > > Проявляется на i586, на x86_64 всё в порядке. На самом деле так было уже очень давно. > Символ __stack_chk_fail_local присутствует только в libc.a, не в libc.so: Ещё он присутствует в libc_nonshared.a, при этом файл libc.so, используемый при компоновке, на самом деле представляет собой ld script: /* GNU ld script Use the shared library, but some functions are only in the static library, so try that secondarily. */ OUTPUT_FORMAT(elf32-i386) GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED ( /lib/ld-linux.so.2 ) ) Т.е., в каждый исполняемый файл или разделяемую библиотеку попадает собственная копия необходимых функций из libc_nonshared.a. Функция __stack_chk_fail_local на самом деле просто вызывает функцию __stack_chk_fail из libc.so.6. Эта промежуточная функция, локальная для разделяемой библиотеки, добавлена с целью оптимизации. Дело в том, что вызов функции __stack_chk_fail из другого модуля должен производиться через PLT, для чего i386 ELF ABI требует перед вызовом загрузить в регистр %ebx указатель на GOT; вызов же локальной для модуля функции __stack_chk_fail_local может производиться напрямую и не требует предварительной инициализации %ebx, а уже в реализации __stack_chk_fail_local в одном экземпляре на каждый модуль присутствует код, устанавливающий требуемое значение %ebx перед вызовом __stack_chk_fail через PLT. В системе команд x86_64, в отличие от i386, есть возможность адресации данных по смещению от адреса текущей команды (%rip), поэтому не требуется занимать отдельный регистр для хранения адреса GOT, и вызов функции через PLT не требует предварительной подготовки, поэтому там функция __stack_chk_fail просто вызывается напрямую, и локальная для модуля функция __stack_chk_fail_local не нужна. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [devel] libc on i586: WTF? 2010-10-16 11:40 ` Sergey Vlasov @ 2010-10-18 3:37 ` REAL 2010-10-18 8:20 ` Dmitry V. Levin 0 siblings, 1 reply; 8+ messages in thread From: REAL @ 2010-10-18 3:37 UTC (permalink / raw) To: ALT Linux Team development discussions Sergey Vlasov пишет: >> Символ __stack_chk_fail_local присутствует только в libc.a, не в libc.so: > > Ещё он присутствует в libc_nonshared.a, при этом файл libc.so, > используемый при компоновке, на самом деле представляет собой ld > script: > > /* GNU ld script > Use the shared library, but some functions are only in > the static library, so try that secondarily. */ > OUTPUT_FORMAT(elf32-i386) > GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED ( /lib/ld-linux.so.2 ) ) > > Т.е., в каждый исполняемый файл или разделяемую библиотеку попадает > собственная копия необходимых функций из libc_nonshared.a. Т.е. мне достаточно будет собирать библиотеки с -lc? glibc-devel-static использовать не нужно? Или я опять что-то не так понял? -- REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [devel] libc on i586: WTF? 2010-10-18 3:37 ` REAL @ 2010-10-18 8:20 ` Dmitry V. Levin 2010-10-18 7:33 ` REAL 0 siblings, 1 reply; 8+ messages in thread From: Dmitry V. Levin @ 2010-10-18 8:20 UTC (permalink / raw) To: ALT Linux Team development discussions [-- Attachment #1: Type: text/plain, Size: 962 bytes --] On Mon, Oct 18, 2010 at 11:37:16AM +0800, REAL wrote: > Sergey Vlasov пишет: > >>Символ __stack_chk_fail_local присутствует только > >>в libc.a, не в libc.so: > > > >Ещё он присутствует в libc_nonshared.a, при этом > >файл libc.so, > >используемый при компоновке, на самом > >деле представляет собой ld > >script: > > > >/* GNU ld script > > Use the shared library, but some functions are only in > > the static library, so try that secondarily. */ > >OUTPUT_FORMAT(elf32-i386) > >GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED ( > >/lib/ld-linux.so.2 ) ) > > > >Т.е., в каждый исполняемый файл или > >разделяемую библиотеку попадает > >собственная копия необходимых функций > >из libc_nonshared.a. > > Т.е. мне достаточно будет собирать > библиотеки с -lc? glibc-devel-static использовать > не нужно? glibc-devel-static для этого не потребуется. Даже -lc не нужно, если вы используете gcc. -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [devel] libc on i586: WTF? 2010-10-18 8:20 ` Dmitry V. Levin @ 2010-10-18 7:33 ` REAL 0 siblings, 0 replies; 8+ messages in thread From: REAL @ 2010-10-18 7:33 UTC (permalink / raw) To: ALT Linux Team development discussions Dmitry V. Levin пишет: >> Т.е. мне достаточно будет собирать >> библиотеки с -lc? glibc-devel-static использовать >> не нужно? > > glibc-devel-static для этого не потребуется. > Даже -lc не нужно, если вы используете gcc. Благодарю. Я использую g77, поэтому нужно -lc. Если будет gcc, соответственно, нужен будет -lgfortran ;) -- REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2010-10-18 8:20 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-10-16 4:26 [devel] libc on i586: WTF? REAL 2010-10-16 11:18 ` Dmitry V. Levin 2010-10-18 3:32 ` REAL 2010-10-18 8:19 ` Dmitry V. Levin 2010-10-16 11:40 ` Sergey Vlasov 2010-10-18 3:37 ` REAL 2010-10-18 8:20 ` Dmitry V. Levin 2010-10-18 7:33 ` REAL
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git