ALT Linux Team development discussions
 help / color / mirror / Atom feed
* [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