Post

Jordan Isaacs
@snowytrees.dev

Been working on using github.com/backtrace-la... which does cross modifying code for negligible overhead flags. But when I tried to use it I got dreaded linker errors with the '__start' and '__stop' symbols for the custom sections that were supposed to be generated at link time missing...

github.comGitHub - backtrace-labs/dynamic_flag: A C library for runtime-flippable feature flags on Linux/x86-64, with negligible overhead in the common caseA C library for runtime-flippable feature flags on Linux/x86-64, with negligible overhead in the common case - backtrace-labs/dynamic_flag

0 reposts0 likes

Jordan Isaacs
@snowytrees.dev

But the sections existed in the object files leaving me flummoxed. Why wasn’t the linker using the sections? So I went down one of the most interesting systems rabbit holes I’ve had recently.

Jordan Isaacs
@snowytrees.dev

So dynamic flag automatically generates sections using inline assembly. One section has the list of all flags. Then there are arbitrarily many other sections that are a “view” into that list of flags for more efficient lookups. There is no access of any sections beyond using '__start' and '__stop'

Jordan Isaacs
@snowytrees.dev

Luckily I had two build flavors with one passing and the other failing. I manually went through every linker flag difference to guess which one was causing issues. And '—gc-sections' looked suspicious. The linker has some crazy complexity to how it decides to GC sections.

Jordan Isaacs
@snowytrees.dev

There has actually been a ton of consideration to handling these sort of “meta” sections that have no direct access and thus do not participate in general GC references. But upon further looking the dynamic flag didn’t use any of the special flags. So I found my bug, the linker was GCing it