Re: Reduce function call costs on ELF platforms

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Reduce function call costs on ELF platforms
Date: 2021-11-22 23:57:45
Message-ID: 20211122235745.yuqi7wlczgeu2j5k@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2021-11-22 17:32:21 -0500, Tom Lane wrote:
> > 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]).

Hm. I didn't really see reasons to not use -Bsymbolic in that thread.

> It sounds like you're not actually proposing that, but I thought it would be
> a good idea to note the hazard here.

I think it'd be good to use, but it'll be much less important once we use
symbol visibility.

> > 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.

No, it is a change at the function callsite thats transparent to the function
itself (unless the called function goes out of its way to do stuff like
inspecting frame pointers or such, but they're not available by default on
most platforms anyway).

It does however change symbol binding, basically making all symbols bound
eagerly. Which I guess theoretically could be considered an ABI change,
because it removes the ability to intercept symbols referenced in a previously
loaded shared library, with a subsequently loaded library (e.g. loaded with
RTLD_DEEPBIND) function before the symbol is used. But that seems like a
stretch. And I think most ELF platforms/linux distributions have/are moving
towards using -Wl,-z,now -Wl,-z,relro also makes symbols bound eagerly.

> 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?

It does require a bit of care in the symbol visibility patch, basically
marking all such symbols as exported (which may happen implicitly via
PG_FUNCTION_INFO_V1). For extensions that are referenced that way that
actually seems like a good thing, because it makes it clearer what could be
referenced that way.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Dilger 2021-11-23 00:21:42 Re: Granting SET and ALTER SYSTE privileges for GUCs
Previous Message Heikki Linnakangas 2021-11-22 23:11:18 Re: Split xlog.c