This is an archive of the discontinued LLVM Phabricator instance.

[llvm-objcopy] Add --redefine-syms
ClosedPublic

Authored by evgeny777 on Feb 5 2019, 1:52 AM.

Diff Detail

Repository
rL LLVM

Event Timeline

evgeny777 created this revision.Feb 5 2019, 1:52 AM
rupprecht added inline comments.Feb 5 2019, 10:29 AM
test/tools/llvm-objcopy/ELF/redefine-symbol.test
7 ↗(On Diff #185256)

Shouldn't this be an error?

tools/llvm-objcopy/CopyConfig.cpp
258 ↗(On Diff #185256)

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.

259 ↗(On Diff #185256)

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.

evgeny777 marked an inline comment as done.Feb 5 2019, 10:40 AM
evgeny777 added inline comments.
test/tools/llvm-objcopy/ELF/redefine-symbol.test
7 ↗(On Diff #185256)

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

evgeny777 marked an inline comment as done.Feb 5 2019, 10:42 AM
evgeny777 added inline comments.
tools/llvm-objcopy/CopyConfig.cpp
259 ↗(On Diff #185256)

Yep, good catch

rupprecht added inline comments.Feb 5 2019, 11:07 AM
test/tools/llvm-objcopy/ELF/redefine-symbol.test
7 ↗(On Diff #185256)

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 ↗(On Diff #185256)

Nit: symbol -> symbols

@jhenderson

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?

@jhenderson

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.

evgeny777 added a comment.EditedFeb 6 2019, 7:33 AM

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 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).

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?

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?

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.

evgeny777 updated this revision to Diff 185744.Feb 7 2019, 4:55 AM

Addressed

jhenderson added inline comments.Feb 7 2019, 5:28 AM
tools/llvm-objcopy/CopyConfig.cpp
268 ↗(On Diff #185744)

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).

269 ↗(On Diff #185744)

I don't think this should be auto. The type isn't obvious.

273 ↗(On Diff #185744)

Ditto.

276–277 ↗(On Diff #185744)

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 ↗(On Diff #185256)

This still needs doing.

evgeny777 updated this revision to Diff 185756.Feb 7 2019, 6:33 AM

Addressed

jhenderson added inline comments.Feb 7 2019, 7:28 AM
test/tools/llvm-objcopy/ELF/redefine-symbol.test
93 ↗(On Diff #185756)

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 ↗(On Diff #185756)

Nit: file is missing new line at end.

tools/llvm-objcopy/CopyConfig.cpp
278–281 ↗(On Diff #185756)

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 ↗(On Diff #185756)

There's already a createFileError in LLVM. Can you use that?

jhenderson accepted this revision.Feb 8 2019, 1:40 AM

LGTM, with the noted fix.

tools/llvm-objcopy/CopyConfig.cpp
278–281 ↗(On Diff #185756)

%lu is the wrong format for a size_t. It should be %zu.

tools/llvm-objcopy/llvm-objcopy.cpp
55–58 ↗(On Diff #185756)

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?

This revision is now accepted and ready to land.Feb 8 2019, 1:40 AM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptFeb 8 2019, 2:33 AM