Details
Diff Detail
Event Timeline
test/tools/llvm-objcopy/ELF/redefine-symbol.test | ||
---|---|---|
7 | Shouldn't this be an error? | |
tools/llvm-objcopy/CopyConfig.cpp | ||
259 | It might be more straightforward (though verbose) to just use the other overload of split that puts thing in a SmallVector, and error if the size != 2. | |
260 | This needs StringSaver to retain these lines once the memory buffer has gone out of scope. I'm able to reproduce a crash w/ asan by removing StringSaver from addGlobalSymbolsFromFile above, and the usage here looks similar. |
test/tools/llvm-objcopy/ELF/redefine-symbol.test | ||
---|---|---|
7 | I don't know. GNU objdump treats this a error. However this line above llvm-objcopy --redefine-sym foo=oof --redefine-sym empty= %t %t2 says that empty symbol names are allowed |
tools/llvm-objcopy/CopyConfig.cpp | ||
---|---|---|
260 | Yep, good catch |
test/tools/llvm-objcopy/ELF/redefine-symbol.test | ||
---|---|---|
7 | Hmm.... that's weird. I guess it's consistent. I'll defer to @alexshap @jakehehrlich @jhenderson if they feel otherwise, but I think it might be fine to deviate from --redefine-sym and require two names -- I could imagine someone accidentally filling a text file with "foo=bar" instead of "foo bar". The downside is that if someone wants to set all their symbols to empty names, they'd have to do it painfully (add --redefine-sym=foo= for each one), but I think it's worth it for the much more common case of not getting the format right on the first try. (The flag case is a less error prone, since foo= makes it obvious that you are assigning a symbol to something empty) |
One question from me: is it possible using GNU objcopy to redefine to/from a name with a space in it this way? Perhaps using quotes or backslashes? Given that spaces in names are likely rare, I think it might be okay to not handle that case, but if GNU objcopy handles it, then we should too.
I think it's probably fine to deviate from GNU in the behaviour of handling lines without pairs in them, assuming that the above is handled in some sensible manner. I'd emit an error in that case.
You need a test for the case where multiple files are specified. Also possibly the case where the same symbol is mentioned multiple times in a file (although this is probably covered enough by the existing tests).
tools/llvm-objcopy/ObjcopyOpts.td | ||
---|---|---|
83 | Nit: symbol -> symbols |
One question from me: is it possible using GNU objcopy to redefine to/from a name with a space in it this way?
Yes. I can redefine to a space (or even an empty string) like this
objcopy --redefine-sym=main=' ' a.out b.out
Still GNU objcopy seems to now allow the same to be done with --redefine-syms <file>
May be pop up warning in llvm-objcopy on such occasions?
I was actually referring to --redefine-syms, i.e. how it looks in a file. Did you mean "not allow" rather than "now allow" in that other statement? I'm not quite sure what you're proposing re. the warning.
I was actually referring to --redefine-syms, i.e. how it looks in a file. Did you mean "not allow" rather than "now allow" in that other statement?
Yes, that's a mistype. I intended to say GNU objcopy does NOT allow single name on a line in a file when --redefine-syms is used. So there seems to be no way to set empty name in this mode.
We can either duplicate this behavior in llvm-objcopy or show warning like this
llvm-objcopy: warning: symbol-list:1: missing new symbol name
I like the warning, especially if it has the line number in of the offending line(s).
Actually, on second thoughts, I think this should be an error. If a user specifies a line in the file that is a bad format, that's as bad as doing the same on the command-line, so should be treated with the same severity.
Actually, on second thoughts, I think this should be an error. If a user specifies a line in the file that is a bad format, that's as bad as doing the same on the command-line, so should be treated with the same severity.
So do you actually want to trigger error in both (cl and file) cases?
If so should there be a way to replace some symbol foo with an empty symbol?
No - the two cases are different, due to the different formats. In the cl case, a missing '=' causes a bad format error. If an '=' is present, the (potentially empty) string after it is the new name. In the file case, the separator is a space character, so the error should occur if there are no spaces (after trimming). That way, if a user writes "foo=bar" in the file, they'll get an error.
If so should there be a way to replace some symbol foo with an empty symbol?
Replacing symbol foo with an empty-name symbol probably is one of those corner cases that we should only support on the command-line.
tools/llvm-objcopy/CopyConfig.cpp | ||
---|---|---|
269 | Nit: use size_t instead of unsigned to match the return type of .size(). Also, Lines.size() should be calculated out-of-line, I think, based on the coding standards (although it only talks about end() calls explicitly, so I could be wrong on this). | |
270 | I don't think this should be auto. The type isn't obvious. | |
274 | Ditto. | |
277–278 | Rather than call error here, this should probably return an llvm::Error which is handled in the calling code. | |
tools/llvm-objcopy/ObjcopyOpts.td | ||
83 | This still needs doing. |
test/tools/llvm-objcopy/ELF/redefine-symbol.test | ||
---|---|---|
93 | This will fail on Windows because "No such file or directory." is Linux specific. You can make it platform independent by replacing it with {{[Nn]}}o such file or directy (note the lack of full-stop and the capitalization). | |
101 | Nit: file is missing new line at end. | |
tools/llvm-objcopy/CopyConfig.cpp | ||
278–281 | Use createStringError here. That also allows you to use printf-style formatting if you want. Also, this error isn't an "illegal_byte_sequence" which is to do with character encoding. It should be something like "invalid_argument" or "parse_failed" or similar. | |
tools/llvm-objcopy/llvm-objcopy.cpp | ||
55–58 | There's already a createFileError in LLVM. Can you use that? |
LGTM, with the noted fix.
tools/llvm-objcopy/CopyConfig.cpp | ||
---|---|---|
278–281 | %lu is the wrong format for a size_t. It should be %zu. | |
tools/llvm-objcopy/llvm-objcopy.cpp | ||
55–58 | It doesn't need to be part of this change, but I wonder if it would make sense for a new createFileError overload to be added alongside the existing one that takes a std::error_code? |
Shouldn't this be an error?