Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't depend on llvm-nm to detect archive indexes #10300

Merged
merged 3 commits into from
Feb 4, 2020
Merged

Conversation

sbc100
Copy link
Collaborator

@sbc100 sbc100 commented Jan 29, 2020

There is an llvm but that mean that certain binary files get mistaken
for COFF object which means llvm-nm will error out:
https://bugs.llvm.org/show_bug.cgi?id=44683

Instead write out own trivial ar parser to detect the presence of that
index.

Fixes: #10195

@sbc100 sbc100 requested a review from kripken January 29, 2020 01:51
Copy link
Member

@kripken kripken left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know much about the AR files, is / how to tell if there's an index?

@@ -8725,6 +8725,15 @@ def test_archive_no_index(self):
self.assertContained('libfoo.a: archive has no index; run ranlib to add one', stderr)
# The default behavior is to add archive indexes automatically.
run_process([PYTHON, EMCC, 'libfoo.a', 'hello_world.o'])
run_process([PYTHON, EMCC, 'libfoo.a', 'hello_world.o'])
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is this line duplicating the one before it?

There is an llvm but that mean that certain binary files get mistaken
for COFF object which means llvm-nm will error out:
  https://bugs.llvm.org/show_bug.cgi?id=44683

Instead write out own trivial ar parser to detect the presence of that
index.

Fixes: #10195
@sbc100 sbc100 merged commit b857693 into master Feb 4, 2020
@sbc100 sbc100 deleted the fix_auto_index branch February 4, 2020 03:34
aheejin added a commit to aheejin/emscripten that referenced this pull request Oct 2, 2020
This test was added in emscripten-core#10300 to check if we can handle non-objects in
archives, especially rust metadata files that start with two leading
zeroes. LLVM's file magic identifier thinks files with two leading
zeroes are COFF files. But Rust metadata files used to start with two
leading zeroes too, resulting in an error in LLVM tools. So emscripten-core#10300
bypassed use of `llvm-nm` to avoid that.

We were still using `llvm-ranlib`, which also ran the LLVM magic
identifier when trying to create a symbol table for an object, but
`llvm-ranlib` so far has ignored those errors. But recently
llvm/llvm-project@a20168d
made them explicit errors, so we couldn't run `llvm-ranlib` anymore with
archives containing objects that start with two leading zeroes.

But this is not relevant anymore because Rust fixed their object file
format in rust-lang/rust#66235, so their files are not mistaken by LLVM
for COFF files anymore. So this PR fixes this test to not include a
binary with two leading zeros, while still testing archival of
non-object files.
aheejin added a commit that referenced this pull request Oct 2, 2020
This test was added in #10300 to check if we can handle non-objects in
archives, especially rust metadata files that start with two leading
zeroes. LLVM's file magic identifier thinks files with two leading
zeroes are COFF files. But Rust metadata files used to start with two
leading zeroes too, resulting in an error in LLVM tools. So #10300
bypassed use of `llvm-nm` to avoid that.

We were still using `llvm-ranlib`, which also ran the LLVM magic
identifier when trying to create a symbol table for an object, but
`llvm-ranlib` so far has ignored those errors. But recently
llvm/llvm-project@a20168d
made them explicit errors, so we couldn't run `llvm-ranlib` anymore with
archives containing objects that start with two leading zeroes.

But this is not relevant anymore because Rust fixed their object file
format in rust-lang/rust#66235, so their files are not mistaken by LLVM
for COFF files anymore. So this PR fixes this test to not include a
binary with two leading zeros, while still testing archival of
non-object files.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

llvm-nm error The end of the file was unexpectedly encountered
2 participants