Re: Preventing abort() and exit() calls in libpq - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Preventing abort() and exit() calls in libpq
Date
Msg-id 202106301439.dji3ms64lxlj@alvherre.pgsql
Whole thread Raw
In response to Re: Preventing abort() and exit() calls in libpq  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Preventing abort() and exit() calls in libpq
List pgsql-hackers
On 2021-Jun-30, Tom Lane wrote:

> 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.

Hah, I didn't think to try that.

> 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.

No objections to that.

> 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?

Well, not really.  I saw it but only after I removed -fprofile-arcs from
Makefile.shlib's link line; but per my other email, that doesn't really
work.

Everything seems to work well for me after removing abort from that grep.

-- 
Álvaro Herrera                        Valdivia, Chile
                        https://www.EnterpriseDB.com/



pgsql-hackers by date:

Previous
From: Alexander Pyhalov
Date:
Subject: Re: Partitioned index can be not dumped
Next
From: Tom Lane
Date:
Subject: Re: Preventing abort() and exit() calls in libpq