Re: Preventing abort() and exit() calls in libpq
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Michael Paquier <michael@paquier.xyz>,
Jacob Champion <pchampion@vmware.com>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
Daniel Gustafsson <daniel@yesql.se>, info@cspug.cz
Date: 2021-06-30T14:09:32Z
Lists: pgsql-hackers
Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > Maybe there's something about the linker flags being used. > ... ah yeah, if I configure with coverage enabled on my machine, it fails in the same way. Ah-hah, yeah, I see it too if I enable profiling. I can confirm that it's not from the abort() call in path.c, because it's still there if I remove that. So this is another case where build infrastructure is injecting abort() calls we didn't ask for. Between this and the icc case, I'm now inclined to give up on trying to forbid abort() calls in libpq. I think the value-add for that is a lot lower than it is for exit() anyway. abort() is something one doesn't toss around lightly. You mentioned __gcov_exit, but I'm not sure if we need an exception for that. I see it referenced by the individual .o files, but the completed .so has no such reference, so at least on RHEL8 it's apparently satisfied during .so linkage. Do you see something different? regards, tom lane
Commits
-
Further restrict the scope of no-exit()-in-libpq test.
- 792259591c0f 15.0 landed
-
Improve build-time check that libpq doesn't call exit().
- 2f7bae2f924d 15.0 landed
-
Fix portability fallout from commit dc227eb82.
- e45b0dfa1f10 15.0 landed
-
Add a build-time check that libpq doesn't call exit() or abort().
- dc227eb82ea8 15.0 landed