On 30.07.24 00:30, Jacob Champion wrote:
But under what circumstances does "the linker doesn't strip out" happen?
If this happens accidentally, then we should have seen some buildfarm
failures or something?
On my machine, for example, I see differences with optimization
levels. Say you inadvertently call pfree() in a _shlib build, as I did
multiple times upthread. By itself, that shouldn't actually be a
problem (it eventually redirects to free()), so it should be legal to
call pfree(), and with -O2 the build succeeds. But with -Og, the
exit() check trips, and when I disassemble I see that pg_malloc() et
all have infected the shared object. After all, we did tell the linker
to put that object file in, and we don't ask it to garbage-collect
sections.
I'm tempted to say, this is working as intended.
libpgcommon is built as a static library. So we can put all the object
files in the library, and its users only use the object files they
really need. So this garbage collection you allude to actually does
happen, on an object-file level.
You shouldn't use pfree() interchangeably with free(), even if that is
not enforced because it's the same thing underneath. First, it just
makes sense to keep the alloc and free pairs matched up. And second, on
Windows there is some additional restriction (vague knowledge) that the
allocate and free functions must be in the same library, so mixing them
freely might not even work.
