[PATCH] D53495: Add OUTPUT_FORMAT linker script directive support.
George Rimar via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Oct 22 09:29:34 PDT 2018
grimar accepted this revision.
grimar added a comment.
This revision is now accepted and ready to land.
LGTM.
================
Comment at: lld/ELF/ScriptParser.cpp:410
+ if (Config->EKind == ELFNoneKind)
+ std::tie(Config->EKind, Config->EMachine) = BfdName;
+
----------------
ruiu wrote:
> grimar wrote:
> > ruiu wrote:
> > > grimar wrote:
> > > > So I think this means LLD will error out when seeing the object file with incompatible architecture after parsing the script containing `OUTPUT_FORMAT`. Behavior is fine, but I think there is no test provided for that case?
> > > I don't think we need that test case.
> > Then you should be able to simplify to
> >
> > `std::tie(Config->EKind, Config->EMachine) = readBfdName();`
> I'm not too picky about aiming 100% test coverage, and I meant that we don't need a test case for that in that sense. I'll add a test for you but we don't need to test for all possible combinations of conditions.
I meant the following scenario:
If we have `file1_386.o` (i386), script saying `OUTPUT_FORMAT("elf64-x86-64")` and `file2_x64.o` (x64).
And invocation: `lld file1_386.o -script script.file file2_x64.o`
Then having the `if (Config->EKind == ELFNoneKind)` line here allows us to the incompatible
architectures error properly. That what I suggested to test initially.
It's also a bit strange that we will accept
`lld file1_386.o -script script.file`
but will fail on
`lld -script script.file file1_386.o`
We could have a test explaining the behavior too.
Though I think it is acceptable for now. Let's go as is then.
================
Comment at: lld/test/ELF/invalid-linkerscript.test:53
# RUN: not ld.lld %t8 no-such-file 2>&1 | FileCheck -check-prefix=ERR8 %s
-# ERR8: , expected, but got y
+# RUN: not ld.lld -m elf_amd64 %t8 no-such-file 2>&1 | FileCheck -check-prefix=ERR8 %s
+# ERR8: unknown output format name: x
----------------
I agree that is not useful. See my comment.
https://reviews.llvm.org/D53495
More information about the llvm-commits
mailing list