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.
