Re: Mark all GUC variable as PGDLLIMPORT - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: Mark all GUC variable as PGDLLIMPORT
Date
Msg-id CAGRY4nwDj-PHi=D1vAOUCJiEAyE4A=orzWv+R3jG0wa1yNk5fQ@mail.gmail.com
Whole thread Raw
In response to Re: Mark all GUC variable as PGDLLIMPORT  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, 23 Aug 2021 at 22:15, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Bruce Momjian <bruce@momjian.us> writes:
> On Sun, Aug 22, 2021 at 09:29:01PM +0800, Julien Rouhaud wrote:
>> Then shouldn't we try to prevent direct access on all platforms rather than
>> only one?

> Agreed.  If Julian says 99% of the non-export problems are GUCs, and we
> can just export them all, why not do it?  We already export every global
> variable on Unix-like systems, and we have seen no downsides.

By that argument, *every* globally-visible variable should be marked
PGDLLIMPORT.  But the mere fact that two backend .c files need to access
some variable doesn't mean that we want any random bit of code doing so.

And yes, I absolutely would prohibit extensions from accessing many
of them, if there were a reasonable way to do it.  It would be a good
start towards establishing a defined API for extensions.

There is: -fvisibility=hidden and __attribute__((visibility("default"))) . Or if you prefer to explicitly mark private symbols, use __attribute__((visiblity("hidden"))) .

In addition to API surface control this also gives you a smaller export symbol table for faster dynamic linking, and it improves link-time optimization.

I could've sworn I proposed its use in the past but I can't find a relevant list thread except quite a recent one. All I can find is [1] . But that is where we should start: switch from a linker script for libpq to using PGDLLIMPORT (actually  it'd be LIBPQDLLIMPORT) in libpq. When -DBUILDING_LIBPQ this would expand to __declspec("dllexport") on Windows and __attribute__((visibility("default"))) on gcc/clang. Otherwise it expands to __declspec("dllimport") on Windows and empty on other targets. This would also be a good time to rename the confusingly named BUILDING_DLL macro to BUILDING_POSTGRES .

The next step would be to have PGDLLIMPORT expand to __attribute__((visibility("default"))) on gcc/clang when building the server itself. This won't do anything by itself since all symbols are already default visibility. But once the "public API" of both function and data symbol is so-annotated, we could switch to building Pg with -fvisibility=hidden by default, and on Windows, we'd disable the linker script that exports all functions using a generated .DEF file.

pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Queries that should be canceled will get stuck on secure_write function
Next
From: Craig Ringer
Date:
Subject: Re: Mark all GUC variable as PGDLLIMPORT