* [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 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: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-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 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
* 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-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
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