On Fri, 26 Sept 2025 at 08:47, Timur Doumler via SG15 <sg15_at_[hidden]>
wrote:

> Hi Ville,
>
> Oh, I see where the misunderstanding came from. Thanks for explaining.
>
> Yes, what you describe matches closely how Iain described his prototype to
> me. And yes, this (link-time or runtime selection of semantic where YOU
> control the compilation) does not require new technology.
>
> What does require new technology is to be able to tell, from an already
> compiled binary (potentially from a 3rd party) with a fixed semantic baked
> in at compile time, which semantic was used in that binary, and then do
> things like Harald suggested (reject the binary if it doesn't have the
> semantic you want) or more generally, make a deterministic choice between
> different versions of the same function compiled with different baked-in
> semantics, at link time.
>

I think it should be possible today:
https://developers.redhat.com/blog/2018/02/20/annobin-storing-information-binaries

When GCC compiles code with the annobin plugin it uses special ELF notes to
record the switches used to compile each object. The linker preserves all
those notes, and you can inspect them in the final executable. We use this
in Red Hat Enterprise Linux so that we can be sure that every object in
every binary is compiled with the expected hardening flags (like
_FORTIFY_SOURCE=2, _GLIBCXX_ASSERTIONS, -fPIE etc.)

If an executable has any objects where the annobin instrumentation shows
missing flags (or the instrumentation is missing entirely), the binary can
be prevented from shipping to customers, unless it's explicitly waived,
with an appropriate justification.

I think this could be used to inspect the binary and enforce a
company-specific requirement that -fcontract-semantic=enforce was used for
every object in the binary.