test: Add test for weak ref to as-needed shared library

[PritamP20]

The original intent of this PR was to fix an issue where --as-needed shared libraries were not being activated when only a weak symbol referenced them.

Initially, this seemed like a divergence from GNU ld and lld, so the change attempted to activate the shared library in that case.

After further investigation and testing with GNU ld and lld, it turned out that both of them do not activate --as-needed shared libraries for weak references. The behavior expected by the mold test (as-needed-weak.sh) is therefore mold-specific. Wild already behaves the same as GNU ld and lld.

Changes in this PR

• Mark as-needed-weak.sh as mold-specific in mold_skip_tests.toml.
• Add a Wild integration test (as-needed-weak.c) to verify the expected behavior: a weak reference should not activate a --as-needed shared library.
• The test ensures the library is not added to DT_NEEDED, matching GNU ld and lld behavior.

Result

Wild’s behavior now has explicit test coverage confirming that weak references do not activate --as-needed shared libraries, consistent with GNU ld and lld.

[davidlattimore]

It might not be an archive. It could also be a regular object file right?

[PritamP20]

Yeah, it can be a regular object file too I'll fix the comment. The main thing this block handles is the case where a weak reference to a shared library wasn't activating it for --as-needed, so it was getting dropped from DT_NEEDED

[davidlattimore]

Do the tests pass for you locally? If they do, then you might want to look at your test-config.toml or copy test-config-ci.toml if you don't have one.

[PritamP20]

I think I understand why my earlier fix was breaking the tests. When try_request_file_id activates a --as-needed DSO for a weak ref, the file becomes loaded. Then in canonicalise_undefined_symbols, the ignore_if_loaded check treats the symbol as defined and skips the ValueFlags::DYNAMIC path. This causes the symbol to keep the DSO’s version metadata (e.g. gmon_start@unversioned) instead of being emitted as a plain undefined dynamic symbol like GNU ld does

[PritamP20]

Hi @davidlattimore,

I'm working on fixing the as-needed-weak.sh mold test. I added logic in resolve_symbol to call try_request_file_id for --as-needed DSOs when a weak reference from a regular object file resolves to one during an executable build.

But this introduces a regression trivial_main_c__ and similar integration tests start failing because wild now pulls libgcc_s.so.1 into DT_NEEDED for weak CRT references like _ITM_deregisterTMCloneTable from crtbeginS.o, which GNU ld doesn’t do.

I tried guarding with symbol_db.get(name, allow_dynamic=false).is_none() so we skip activation if a static alternative exists, but on Alpine musl CI there’s no static provider for those symbols in libgcc.a, so the guard doesn’t help.

Not sure if as-needed-weak.sh is testing mold-specific behavior that differs from GNU ld. If that’s the case, should the test remain skipped, or is there a better way to distinguish the fn1 case (user weak ref should activate DSO) from the _ITM_* case (CRT weak ref should not activate)?

[davidlattimore]

Usually in cases like this, it's necessary to do some experiments. I'd suggest writing a test using our own testing framework. We probably want to do that anyway, since we want our test suite to be reasonably complete when run without the external test suites. That'll make it easier to run with GNU ld and / or LLD so that you can confirm if they have the same behaviour. You could also try running the mold test with GNU ld to see if it passes.

[PritamP20]

@davidlattimore sure I will experiment with all the edge scenario which are possible and let you know where i land with it

[PritamP20]

I re-ran the test with GNU ld and lld to double check. Both of them fail the mold test as well, so it seems this behaviour is mold-specific, Wild might already be behaving correctly here

I will add a small Wild test to confirm the expected behaviour.

[davidlattimore]

Thanks for investigating. It'd be useful to also update mold_skip_tests.toml. e.g. add a comment on that test that says something like "Mold-specific behaviour". It's fine to do it in the same PR as adding the new test since they're pretty related.

[davidlattimore]

Thanks. Always good to see our test coverage improve :)

[davidlattimore]

Looks like there's a compilation error with the merge

[davidlattimore]

If you wanted, you could add the following instead:

//#Shared:force-dynamic-linking.c
//#DiffIgnore:.dynamic.DT_NEEDED

[lapla-cogito]

Also, could you update the PR's description? This would be useful for others to review later.

[davidlattimore]

Also, could you update the PR's description? This would be useful for others to review later.

I already changed the PR title. Unless there's further issues with the title?

[lapla-cogito]

I don't see any issues with the title itself, but having the title and description content significantly differ would only cause confusion, which is why I'd like Pritam to update the content.

[davidlattimore]

Oh, right. Sorry, you did say description. I often just delete the description from the commit message when I merge, so I didn't pay any attention to that.

[PritamP20]

@davidlattimore @lapla-cogito Thanks for the review and feedback. I will update the PR description so that it matches the changes and conclusions made.

[davidlattimore]

Sorry, you possibly need //#Mode:dynamic too. See other tests that use force-dynamic-linking.c.

[PritamP20]

@davidlattimore yeah, I figured it out. I'm testing it locally first before pushing the update.

[davidlattimore]

For the error:

section.got
  wild Section missing
  ld OK

It's fine to just diffignore it. Wild doesn't emit the GOT if it isn't needed, so differences like this are currently pretty common.

[PritamP20]

@lapla-cogito I have updated the PR description, can you review it once

[lapla-cogito]

Thanks! Looks good.