Page MenuHomePhabricator

LLD: Core: Fix file ordinals of archive members.
Needs ReviewPublic

Authored by ruiu on Mar 3 2015, 8:18 PM.
This revision needs review, but there are no reviewers specified.



Previously archive file members got random-ish file ordinals because
file ordinals were assigned in the same order as the resolver needs
them. In LLD, atoms in the output should be ordered in the same as
in the command line, but it was not true for archive files.

This patch (partially) fixes the issue. Now, member files get larger
file ordinals than the archive file but not larger than the next file.
So, after atoms are sorted by file ordinals, they are sorted in the
same order as in the command line.

The reason why it's partial is because the order of members in the
same archive still depends on the resolution order. This needs to be
fixed in future.

Diff Detail

Event Timeline

ruiu updated this revision to Diff 21171.Mar 3 2015, 8:18 PM
ruiu retitled this revision from to LLD: Core: Fix file ordinals of archive members..
ruiu updated this object.
ruiu edited the test plan for this revision. (Show Details)
ruiu added a project: lld.
ruiu added a subscriber: Unknown Object (MLST).

At least on Gnu/ELF what I have seen is the order in the output is how symbols/files were resolved. No?? Do you have a test that fails on Gnu flavor and ELF that doesn't match real gnu behavior?

ruiu added a comment.Mar 4 2015, 10:33 AM

I believed that you wrote this code and was aware of the thing. But as a refresher, the order of symbol resolution and file resolution are not the same. Only object files are visited in order. Files in an archive file is visited only when it's needed. If archive files are grouped with -( and -), the order to visit files in the archives is not the same as the order in the input file list.

Previously we set a new and largest ordinal to a file in an archive file as we visit that. So the files in archive files got ordinals in the resolution order, not in the input file order.

shankarke added inline comments.

The member ordinal seems wrong, it should be the next ordinal available for GNU.