[PATCH] D150508: [LLD] Do not assume /guard:cf always set together with /guard:ehcont

[Phoebe Wang via Phabricator via llvm-commits]

pengfei added inline comments.


================
Comment at: lld/COFF/Writer.cpp:1735-1740
     // If the object was compiled with /guard:cf, the address taken symbols
     // are in .gfids$y sections, the longjmp targets are in .gljmp$y sections,
     // and ehcont targets are in .gehcont$y sections. If the object was not
     // compiled with /guard:cf, we assume there were no setjmp and ehcont
     // targets, and that all code symbols with relocations are possibly
     // address-taken.
----------------
rnk wrote:
> Please update this comment to avoid discussing EH continuations.
> 
> My understanding is that if you compile with `/guard:ehcont-` and link with `/guard:ehcont`, then attempts to catch exceptions in the unprotected object files will crash the program with control flow violations, but correct me if I am wrong. There is no attempt to conservatively handle objects that catch exceptions but not `/guard:ehcont`, they must all be recompiled with EH continuations, correct?
Good catch!

This patch is to fix a problem as a side effect of D150645. User expected both `cf` and `ehcont` bits are set in the obj files and link with both. However, we only have `ehcont` present due to the bug.
I don't know if this would be a problem in reality, but separating `cf` and `ehcont` in lld matches with MS link. So I think it's still good to go with this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D150508