Re: longjmp clobber warnings are utterly broken in modern gcc - Mailing list pgsql-hackers

From Martijn van Oosterhout
Subject Re: longjmp clobber warnings are utterly broken in modern gcc
Date
Msg-id 20150125223922.GA14284@svana.org
Whole thread Raw
In response to longjmp clobber warnings are utterly broken in modern gcc  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: longjmp clobber warnings are utterly broken in modern gcc
List pgsql-hackers
On Sun, Jan 25, 2015 at 02:02:47PM -0500, Tom Lane wrote:
> and compared the assembly language generated with and without adding
> "volatile" to Tmpfd's declaration.  Without "volatile" (ie, in the
> code as shipped), gcc optimizes away the assignment "Tmpfd = -1"
> within PG_TRY, and it also optimizes away the if-test in PG_CATCH,
> apparently believing that control cannot transfer from inside the
> PG_TRY to the PG_CATCH.  This is utterly wrong of course.  The issue
> is masked because we don't bother to test for a failure return from the
> second close() call, but it's not hard to think of similar coding
> patterns where this type of mistaken optimization would be disastrous.
> (Even here, the bogus close call could cause a problem if we'd happened
> to open another file during the last part of the PG_TRY stanza.)

<snip>

> This is scary as hell.  I intend to go around and manually audit
> every single PG_TRY in the current source code, but that is obviously
> not a long-term solution.  Anybody have an idea about how we might
> get trustworthy mechanical detection of this type of situation?

It's a bit of a long shot, but perhaps if you put something like:

asm volatile("":"":"":"memory")

at the beginning of the catch-block it might convince the compiler to
forget any assumptions about what is in the local variables...

Hope this helps,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> He who writes carelessly confesses thereby at the very outset that he does
> not attach much importance to his own thoughts.  -- Arthur Schopenhauer

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: longjmp clobber warnings are utterly broken in modern gcc
Next
From: Tom Lane
Date:
Subject: Re: longjmp clobber warnings are utterly broken in modern gcc