This is an archive of the discontinued LLVM Phabricator instance.

[LLD] [COFF] Fix export directives in object files from -includeoptional
ClosedPublic

Authored by mstorsjo on Aug 22 2022, 2:41 AM.

Details

Summary

When an object file contains an export directive, we normally do some
amount of deferred processing of them at the end of the linking
process. The -includeoptional option was handled after this, and
any object files (defining new exports) weren't handled.

Move the handling of the -includeoptional into the same late loop
which does the fixups for e.g. export directives.

Ideally, this would also be done for object files that are pulled
in by the wrap options, and for mingw autoimports, but those changes
require more modifications, to make them safe for potentially
being executed multiple times.

Diff Detail

Event Timeline

mstorsjo created this revision.Aug 22 2022, 2:41 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 22 2022, 2:41 AM
Herald added a subscriber: StephenFan. · View Herald Transcript
mstorsjo requested review of this revision.Aug 22 2022, 2:41 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 22 2022, 2:41 AM

Unfortunately I lack a lot of context here so cannot tell if there are alternative solutions.
How expensive (in terms of performance) is calling updateLinkLoop that many times?

rnk added inline comments.Aug 22 2022, 1:56 PM
lld/COFF/Driver.cpp
2194

Personally, I think long lambdas can make it hard to figure out the structure of the code, so I'd like to try and avoid them if possible, and if necessary, make it a standalone function or method.

2234–2235

Can this not be moved into the body of the loop?

2244

I'm not sure if addWrappedSymbols can be called multiple times, but if it can, or if it can be made safe such that it is only done once, I'd suggest moving it into the loop as well.

Unfortunately I lack a lot of context here so cannot tell if there are alternative solutions.
How expensive (in terms of performance) is calling updateLinkLoop that many times?

I think it might cost a little bit - but I think, in rough terms, that we already run it once or more for the bulk of the linking, and this adds mostly one or two more rounds in the end. But I guess it'd be good to get proper numbers for it.

lld/COFF/Driver.cpp
2234–2235

Hmm, good question. I guess it could be handled that way - let me try that...

2244

I'll see if that's possible.

FWIW we have yet another run() invocation further below, in the if (config->autoImport || config->stdcallFixup) {, but that one doesn't even loop currently - not sure if we'd want to fuse that into the main loop too...

Unfortunately I lack a lot of context here so cannot tell if there are alternative solutions.
How expensive (in terms of performance) is calling updateLinkLoop that many times?

I think it might cost a little bit - but I think, in rough terms, that we already run it once or more for the bulk of the linking, and this adds mostly one or two more rounds in the end. But I guess it'd be good to get proper numbers for it.

At least for the size of link jobs I have to test with here, with a total runtime of 1241 ms, the main loop iteration doesn't add up to even 1 ms.

mstorsjo added inline comments.Aug 23 2022, 1:51 AM
lld/COFF/Driver.cpp
2234–2235

After refamiliarizing myself with these parts of the COFF linker - yes, this should definitely just be moved into the current loop.

2244

Yes, ideally we'd move that and ctx.symtab.loadMinGWSymbols(); into the loop as well. But making them safe to potentially be run multiple times is more effort, but is a riskier change, and less backportable, so I think I'd hold off of that until a separate, potential later change.

mstorsjo updated this revision to Diff 454747.Aug 23 2022, 1:55 AM

Move handling of the -includeoptional options into the same loop as export.

mstorsjo edited the summary of this revision. (Show Details)Aug 23 2022, 1:56 AM
This revision is now accepted and ready to land.Aug 25 2022, 12:49 AM