Re: Preventing abort() and exit() calls in libpq
Alvaro Herrera <alvherre@alvh.no-ip.org>
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
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-30T13:10:06Z
Lists: pgsql-hackers
On 2021-Jun-30, Alvaro Herrera wrote:
> On 2021-Jun-29, Tom Lane wrote:
>
> > Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> > > Ah, I nm'd all files in src/interfaces/libpq and got no hits for abort.
> > > But I did get one in libpgport_shlib.a:
> >
> > > path_shlib.o:
> > > U abort
> >
> > Yeah, there is one in get_progname(). But path.o shouldn't be getting
> > pulled into libpq ... else why aren't all the animals failing?
>
> 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.
If I remove -fprofile-arcs from CFLAGS, then abort is no longer present,
but we still get a fail because of __gcov_exit. I suppose if you'd add
an exception for __cxa_atexit, the same place could use one for
__gcov_exit.
I'm not sure what to make of the -fprofile-arcs stuff though.
--
Álvaro Herrera Valdivia, Chile
https://www.EnterpriseDB.com/
"Java is clearly an example of money oriented programming" (A. Stepanov)
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