Add N_NO_DEAD_STRIP flag to section symbols

[filipnavara]

Extracted from #106224.

PR #103039 added N_NO_DEAD_STRIP flag to all symbols emitted by ILC and enabled the dead code stripping in the native linker.

It failed to handle one specific edge case that is luckily not happening in the wild. If the first node emitted into a section has a symbol with non-zero offset NN the first N_NO_DEAD_STRIP symbol is not pointing at the start of the section. The native linker then splits up the section into atom and the first atom from offset 0 to offset NN is never referenced and becomes eligible for dead code stripping. Since we emit a symbol for each section start (for use in section-relative relocations) we can just mark the symbol with N_NO_DEAD_STRIP to resolve the issue.

[dotnet-policy-service]

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

[MichalStrehovsky]

/azp run runtime-nativeaot-outerloop, runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[MichalStrehovsky]

/azp run runtime-nativeaot-outerloop, runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[MichalStrehovsky]

Cc @ivanpovazan @dotnet/jit-contrib @dotnet/ilc-contrib for Apple-specific ObjWriter change. Looks reasonable to me but don't know much about Apple stuff.

[jkotas]

LGTM

@filipnavara I assume that we do not need to backport this fix to .NET 9. Correct?

[filipnavara]

I assume that we do not need to backport this fix to .NET 9. Correct?

I am on a verge on this one. On one hand it's not something that I saw in practice so it may not meet the bar. On the other hand, if it ever happens it will be incredibly difficult to trace it back to the root cause. Note the -dead_strip on Apple linker was only re-enabled in .NET 9 and hence this is a code path that didn't see any substantial usage in the wild yet.

[ivanpovazan]

The change looks good to me.
I am curious though, how did you find out the edge case that the previous PR did not cover?

[filipnavara]

I am curious though, how did you find out the edge case that the previous PR did not cover?

It was result of the discussion in #106224. Michal pointed out that MethodTables are emitted with prepended GCDesc data in the front and the actual symbol is defined with non-zero offset in relation to the data. If this was emitted as the first thing in the data section we would hit this edge case. Luckily, it seems that in most cases we get some other data emitted in front with zero-offset symbol, and so the GCDesc part becomes part of the preceding linker atom which is already marked as N_NO_DEAD_STRIP.

I tested the PR #106224 with both the old ld64 linker and the new ld-prime linker (which is still disabled by default in .NET), and I actually hit a case that exposed this bug. That said, it was most likely an artifact of other (local) changes and not reproducible in the wild.