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