This is an archive of the discontinued LLVM Phabricator instance.

[LLD] [COFF] Improve the autoexport check for symbols from import libraries with -opt:noref
ClosedPublic

Authored by mstorsjo on Nov 14 2017, 3:34 AM.

Details

Summary

If -opt:noref is specified, they can end up with isLive() == 1 when the autoexport check is run.

To reduce the risk of potential issues, only consider exporting DefinedRegular and DefinedCommon, nothing else.

Diff Detail

Repository
rL LLVM

Event Timeline

mstorsjo created this revision.Nov 14 2017, 3:34 AM
mstorsjo retitled this revision from [COFF] Don't crash when checking for autoexporting of symbols without a file to [LLD] [COFF] Don't crash when checking for autoexporting of symbols without a file.
rnk edited edge metadata.Nov 14 2017, 2:12 PM

Do you mind digging a little bit so we can get a test case for it? Is there some way to get symbol definitions from .drectives like ELF with --defsym or something?

In D40014#925289, @rnk wrote:

Do you mind digging a little bit so we can get a test case for it? Is there some way to get symbol definitions from .drectives like ELF with --defsym or something?

Ok, I can try to dig closer and see where it actually is coming from.

mstorsjo updated this revision to Diff 122991.Nov 15 2017, 1:52 AM
mstorsjo retitled this revision from [LLD] [COFF] Don't crash when checking for autoexporting of symbols without a file to [LLD] [COFF] Improve the autoexport check for symbols from import libraries with -opt:noref.
mstorsjo edited the summary of this revision. (Show Details)

Identified the actual root cause, improved the related code further by checking for specific types of Defined symbols, added a test.

rnk accepted this revision.Nov 15 2017, 2:18 PM

lgtm, definitely don't want to auto-export that imported data. The absolute symbol thing can be a follow-up change.

COFF/MinGW.cpp
94 ↗(On Diff #122991)

These are the Defined symbol kinds:

DefinedRegularKind = 0,
DefinedCommonKind,
DefinedLocalImportKind,
DefinedImportThunkKind,
DefinedImportDataKind,
DefinedAbsoluteKind,
DefinedSyntheticKind,

I can't think of any synthetic symbols that we'd want to auto-export, but it's definitely possible to define an absolute symbol in an object file that should be auto-exported, right? The linker-generated absolute symbols will probably fail the getFile() null check below.

This revision is now accepted and ready to land.Nov 15 2017, 2:18 PM
In D40014#926637, @rnk wrote:

lgtm, definitely don't want to auto-export that imported data. The absolute symbol thing can be a follow-up change.

I can amend it to allow absolute symbols before committing - I wasn't quite sure what they were originally, but I guess it can make sense to export them as well.

pcc edited edge metadata.Nov 15 2017, 3:04 PM

I didn't think that the pe format allowed absolute symbols to be exported.

ruiu edited edge metadata.Nov 15 2017, 5:35 PM

Please add comments to describe new code.

In D40014#926966, @ruiu wrote:

Please add comments to describe new code.

Ok, maybe like this?

// Only allow the symbol kinds that make sense to export;
// in particular, disallow import symbols.
if (!isa<DefinedRegular>(Sym) && !isa<DefinedCommon>(Sym))

And

// Check that file is non-null before dereferencing it,
// symbols not originating in regular object files probably shouldn't be exported.
if (!Sym->getFile())
ruiu added a comment.Nov 15 2017, 10:53 PM

Sounds good.

This revision was automatically updated to reflect the committed changes.