[PATCH] D147975: [StackProtector] don't check stack protector before calling nounwind functions

[Eli Friedman via Phabricator via llvm-commits]

efriedma added a comment.

In D147975#4262071 <https://reviews.llvm.org/D147975#4262071>, @nickdesaulniers wrote:

> In D147975#4259865 <https://reviews.llvm.org/D147975#4259865>, @efriedma wrote:
>
>>> I think noreturn is a red-herring
>>
>> noreturn without nounwind serves as a hint that the callee unconditionally throws an exception.  (The only other alternatives are that the callee unconditionally calls abort(), or unconditionally spins in an infinite loop; such functions are relatively rare in most codebases.)  But it's not really a strong heuristic; functions that are noreturn aren't guaranteed to throw, and functions that aren't noreturn frequently throw.
>
> Is that a vote of confidence for or against this patch?

For, I guess.  It's fundamentally a heuristic, and I don't think the cost/benefit works out for diagnosing "noreturn nounwind" functions.

>> Longer-term, it might make sense to consider encoding information about the stack canary into DWARF data; if the unwinder can check the canary itself, that catches the relevant cases without a bunch of inline code.
>
> DWARF does encode location lists which IIRC may contain which stack slot certain variables reside in for certain ranges of the program counter.  I could imagine a special new tag to say "here's where the stack canary is."
>
> What happens if code is built with `-g0`? Does that mean such info is not available? Or does C++ always emit such metadata?

I was thinking alongside DWARF unwind (which is not debug info; it's the info necessary to do EH unwind).  I haven't thought through how it would be encoded.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D147975/new/

https://reviews.llvm.org/D147975