https://cs.chromium.org/chromium/src/tools/checkbins/checkbins.py?q=checkbins&sq=package:chromium&dr&l=76 :

    # Check for /SAFESEH. Binaries should meet one of the following
    # criteria:
    #   1) Have no SEH table as indicated by the DLL characteristics
    #   2) Have a LOAD_CONFIG section containing a valid SEH table
    #   3) Be a 64-bit binary, in which case /SAFESEH isn't required
    #
    # Refer to the following MSDN article for more information:
    # http://msdn.microsoft.com/en-us/library/9a89h429.aspx
    if (pe.OPTIONAL_HEADER.DllCharacteristics & NO_SEH_FLAG or
        (hasattr(pe, "DIRECTORY_ENTRY_LOAD_CONFIG") and
         pe.DIRECTORY_ENTRY_LOAD_CONFIG.struct.SEHandlerCount > 0 and
         pe.DIRECTORY_ENTRY_LOAD_CONFIG.struct.SEHandlerTable != 0) or
        pe.FILE_HEADER.Machine == MACHINE_TYPE_AMD64):
      if options.verbose:
        print "Checking %s for /SAFESEH... PASS" % path
    else:
      success = False
      print "Checking %s for /SAFESEH... FAIL" % path

(It's a hand-rolled variant of binskim / binscope -- I wonder if we should try running those too?)

The 4 binaries all use /ENTRY: (3 actually use the same cc file with the same /ENTRY: flag) or /NOENTRY:

https://cs.chromium.org/chromium/src/chrome/common/win/BUILD.gn?q=eventlog_provider+file:build.gn&sq=package:chromium&dr=C&l=37

https://cs.chromium.org/chromium/src/remoting/host/win/BUILD.gn?q=remoting_desktop+file:build.gn&sq=package:chromium&dr=C&l=459

https://cs.chromium.org/chromium/src/remoting/host/win/BUILD.gn?q=remoting_desktop+file:build.gn&sq=package:chromium&dr=C&l=315

https://cs.chromium.org/chromium/src/remoting/host/win/BUILD.gn?q=remoting_desktop+file:build.gn&sq=package:chromium&dr=C&l=285

args.gn on that bot: https://logs.chromium.org/v/?s=chromium%2Fbb%2Fchromium%2FWin%2F66203%2F%2B%2Frecipes%2Fsteps%2Fgenerate_build_files%2F0%2Fstdout

goma_dir = "C:\\b\\c\\goma_client"
is_component_build = false
is_debug = false
skip_archive_compression = false
strip_absolute_paths_from_debug_symbols = true
symbol_level = 1
target_cpu = "x86"
use_goma = true

(and, on the failing build, implicitly use_lld=true)

…ok, I really need to do something else until Thu, sorry :-(

rnk: Does blocking on the roll mean there's a fix upstream already?

> rnk: Does blocking on the roll mean there's a fix upstream already?

No, but it's a quick fix, and I really just wanted to link the bugs together. It will be blocked on the roll soon enough that I didn't feel like marking the roll blocked on fixing this bug, and then flipping the relationship.

---

I think this is just a small variance in our safeseh implementation. I linked remoting_host.exe on Linux and ran llvm-readobj -coff-load-config -headers on it. This is the important stuff:

...
  Characteristics [ (0xC140)
    IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE (0x40)
    IMAGE_DLL_CHARACTERISTICS_GUARD_CF (0x4000)
    IMAGE_DLL_CHARACTERISTICS_NX_COMPAT (0x100)
    IMAGE_DLL_CHARACTERISTICS_TERMINAL_SERVER_AWARE (0x8000)
  ]
...
LoadConfig [
...
  SecurityCookie: 0x404000
  SEHandlerTable: 0x0
  SEHandlerCount: 0
...

I think to match checkbin's expectations, we need to set IMAGE_DLL_CHARACTERISTICS_NO_SEH when there are zero exception handlers in the binary. We currently only set the flag when there is no load config present, i.e. the user is building a DLL that doesn't link against the MSVC CRT, which is common for mingw users. We should probably just make it conditional on the presence of exception handlers.

r330300 should fix this.