Re: Reduce function call costs on ELF platforms

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Reduce function call costs on ELF platforms
Дата
Msg-id 4103760.1637620341@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Reduce function call costs on ELF platforms  (Andres Freund <andres@anarazel.de>)
Ответы Re: Reduce function call costs on ELF platforms  (Andres Freund <andres@anarazel.de>)
Re: Reduce function call costs on ELF platforms  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Список pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> Basically they way we currently build our extensions, the compiler & linker
> assume every symbol inside the extension libraries needs to be interceptable
> by the main binary. Which means that all function calls to symbols visible
> outside the current translation unit need to be made indirectly via the PLT.

Yeah, that would be nice to improve.

> The easier approach for this class of issues is to use the linker option
> -Bsymbolic.

I don't recall details, but we've previously rejected the idea of
trying to use -Bsymbolic widely; apparently it has undesirable
side-effects on some platforms.  See commit message for e3d77ea6b
(hopefully there's some detail in the email thread [1]).  It sounds
like you're not actually proposing that, but I thought it would be
a good idea to note the hazard here.

> By compiling with -fno-plt, the above becomes:

Does -fno-plt amount to an ABI change?  If so, I'm worried that it'd
break the ability to compile extensions with a different compiler.

Also, we have at least some places where there actually are cross-calls
between extensions, eg hstore_perl -> plperl.  Do we need to worry about
breaking those?

            regards, tom lane

[1] https://www.postgresql.org/message-id/flat/153626613985.23143.4743626885618266803%40wrigleys.postgresql.org



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: LogwrtResult contended spinlock
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Split xlog.c