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
Event Timeline
llvm/tools/llvm-objcopy/CopyConfig.cpp | ||
---|---|---|
285–286 | 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 | ||
---|---|---|
285–286 | 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 | ||
---|---|---|
285–286 |
Shouldn't it should just be a struct then? struct { FileFormat Format; MachineInfo Machine; }; | |
llvm/tools/llvm-objcopy/llvm-objcopy.cpp | ||
32 | Why has this been added? | |
142 | 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 | ||
---|---|---|
285–286 | 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 | 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 | I don't think you need to use auto here. |
llvm/tools/llvm-objcopy/CopyConfig.cpp | ||
---|---|---|
288–290 | 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–463 | This should use a StringSwitch (I suppose adding an Unrecognized file format type to handle the 'else' part?) | |
473–475 | 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–463 | 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 | ||
---|---|---|
458 | 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 | ||
---|---|---|
458 | 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" |
As this is only used in the .cpp, it can be moved in there.