Use an enum instead of string to hold the output file format in Config.InputFormat and Config.OutputFormat. It's essential to support other output file formats other than ELF.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
llvm/tools/llvm-objcopy/CopyConfig.cpp | ||
---|---|---|
279 ↗ | (On Diff #204398) | I think it would be nicer to use a tuple with an enumeration to give the values names rather than "first" and "second" |
llvm/tools/llvm-objcopy/CopyConfig.cpp | ||
---|---|---|
279 ↗ | (On Diff #204398) | What is an elegant way to get an element from tuple using enum? We need to cast the enum values so it should be std::get<static_cast<std::size_t>(Foo::Bar)>(Tuple). It looks verbose a bit to me. |
Could you explain a bit more the motivation behind this change, please? If I'm not mistaken, it's to allow using input and output format with non-ELF (e.g. COFF and Mach-O) targets?
llvm/tools/llvm-objcopy/CopyConfig.cpp | ||
---|---|---|
279 ↗ | (On Diff #204398) |
Shouldn't it should just be a struct then? struct { FileFormat Format; MachineInfo Machine; }; |
llvm/tools/llvm-objcopy/llvm-objcopy.cpp | ||
32 ↗ | (On Diff #204398) | Why has this been added? |
135 ↗ | (On Diff #204398) | Refer -> See |
Yes, that's correct. I'd like to use FileFormat instead of a target string for Config.OutputFormat to allow calling non-ELF implementations in executeObjcopyOnRawBinary.
llvm/tools/llvm-objcopy/CopyConfig.cpp | ||
---|---|---|
279 ↗ | (On Diff #204398) | struct sounds good to me. I'll use it here. |
- Replaced std::pair with a struct.
- Refer -> See
llvm/tools/llvm-objcopy/llvm-objcopy.cpp | ||
---|---|---|
32 ↗ | (On Diff #204398) | Oh I forgot to remove this include. Thanks. |
LGTM, with one nit. Also, if I understand it correctly, this change should have no functional change, right? In that case, please tag the summary with [NFC] (i.e. [llvm-objcopy][NFC] Refactor output target parsing) when you commit.
llvm/tools/llvm-objcopy/CopyConfig.cpp | ||
---|---|---|
324 ↗ | (On Diff #204665) | I don't think you need to use auto here. |
llvm/tools/llvm-objcopy/CopyConfig.cpp | ||
---|---|---|
288 ↗ | (On Diff #204734) | I haven't looked at the full list of bfd targets (for macho/coff in particular), but do we need the extra field, or can we infer it from starting with "elf"? |
457–462 ↗ | (On Diff #204734) | This should use a StringSwitch (I suppose adding an Unrecognized file format type to handle the 'else' part?) |
473–475 ↗ | (On Diff #204734) | I'm not sure this is really an error. Behold: $ echo 'int x=0;' | ~/dev/clang -x c -c - -o /tmp/bss.o $ objcopy -Ielf32-x86-64 /tmp/bss.o /tmp/bss2.o $ file /tmp/bss.o /tmp/bss2.o /tmp/bss.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped /tmp/bss2.o: ELF 32-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped |
- Refactored a bit.
llvm/tools/llvm-objcopy/CopyConfig.cpp | ||
---|---|---|
457–462 ↗ | (On Diff #204734) | I think we don't need Unrecognized for now because currently we simply ignore unrecognized input formats and guess the file format by createBinary. |
llvm/tools/llvm-objcopy/CopyConfig.cpp | ||
---|---|---|
471 ↗ | (On Diff #205235) | ignores -> ignore I'm not really sure what this is trying to point out though. Is it an existing bug in llvm-objcopy or one you are introducing? |
llvm/tools/llvm-objcopy/CopyConfig.cpp | ||
---|---|---|
471 ↗ | (On Diff #205235) | It's an existing bug; we handle "-I binary" and "-I ihex", but specifying "-Ielf32..." is the same as not specifying it at all. Maybe a clearer message would be "ignore the target for non-binary/ihex formats" |
LGTM, with one comment fix.
llvm/tools/llvm-objcopy/CopyConfig.cpp | ||
---|---|---|
471 ↗ | (On Diff #205489) | Nit: We -> we |