Addressed the review comments.
Make sure to mention in the commit comment that this also quotes certain symbol names.
Going with %s together with StringRef::str() + .c_str() for formatting. Will use this form for later change to unify on createStringError() then.
Applied the suggested changes.
By the way, @jakehehrlich may remember exactly what the intended behaviour is in llvm-objcopy for ELF and combining rules. We discussed it a while back, but I can't remember them exactly, but it was something like explicit section keeps trump implicit section strips, and two explicits are an error. You might want to double-check with him.
Sat, Jan 19
Fri, Jan 18
Updated to test how --only-section combined with --strip-debug behaves - matching GNU objcopy's behaviour.
Just to confirm, the desired behaviour of combining certain switches (e.g. --strip-debug and --only-section) is for the explicitly mentioned --only-section section to be kept despite it potentially being removed by the other switch?
Applied @jhenderson's suggestions.
Thu, Jan 17
Adding another COFF-knowledgeable reviewer
Applied @jhenderson's suggestions. But I also split the input data into a separate yaml file in Inputs, as I'm going to use the same input for another test.
Fixed @jhenderson's suggestions.
Wed, Jan 16
It'd be nice if someone else could take a pass too, especially for any COFF-specific aspects, but LGTM
Tweaked the scope of lambdas in removeSections to avoid use-after-free of stack variables in the implementation of the lambda captures, as pointed out by asan.
Applied @rupprecht's suggestions.
Tue, Jan 15
Using a lambda that takes StringRef, renamed the lambda parameter to match coding conventions. Will commit tomorrow.
Mon, Jan 14
LGTM. I'm assuming that the -1 SectionNumber is what makes them absolute?
Sat, Jan 12
I came to the conclusion that setting the Characteristics flags is mostly orthogonal to the stripping of the symbols/relocs (the flag discussed before is actually only relevant for whether executables/DLLs are loadable at a different address than the default), so I split out that part of the patch and I might revisit it later, but it's not essential for the functionality of this patch.
Fri, Jan 11
Alternatively, I could just skip setting the characteristics flags altogether in this patch, as I don't think anything actually reads them on object files, and the context here (removing relocations) only is relevant for object files - base relocs on executables/DLLs are untouched. We can always add them later if deemed necessary. WDYT?
Using a ternary operator as suggested.
When doing this, GNU objcopy sets a few Characteristics flags as well - I'm only setting one of them as the other ones are documented to be deprecated. I'd like to have @rnk's opinion on this part.
My suggestion would be to continue setting the deprecated characteristics flags for --strip-all-gnu, but not for --strip-all, if I understand the meaning of the difference between the two flags. --strip-all-gnu should be for more extreme compatibility between gnu, --strip-all is allowed to be a bit more aggressive.
But I have never heard of characteristics before, maybe this is a case where we want to break GNU objcopy compatibility (we don't aim to be bit-for-bit compatible; even GNU-matching flags will different in minor aspects).
Probably best to let @rnk comment on characteristics.
Added an undefined external to the tests, changed the code comment to use CLI parameter names.
Split testes into two separate files, with one shared yaml source in the Inputs directory.
I'm not quite sure I follow why this only affects executable files? Why is this an issue in PE but not plain COFF?
Initially I tried to make the output of llvm-objcopy as close as possible to the output from various tools (llvm-mc and MSVC), and to achieve this, I only skipped including the symbol/string table in executables, while keeping it present in object files.
I know that exactly matching the output of another tool shouldn't be a goal in itself, but I don't know if there are tools out there that would flat out reject an object file with an omitted symbol/string table, as opposed to an empty symbol/string table. So keeping this distinction probably is safer.
So the behaviour change is that for objects, the object now has a pointer to the symbol table, which it didn't before. I think I get it now. The problem is the writeSymbolStringTables function, and you want that to always write a size for object files, even if the table is empty, right?
Did the suggested changes to the test, added the distinction that --discard-all keeps undefined local symbols.