This is an archive of the discontinued LLVM Phabricator instance.

[llvm-objcopy][NFC] refactor restoreStatOnFile out of llvm-objcopy.
ClosedPublic

Authored by avl on Apr 14 2022, 1:35 PM.

Details

Summary

Functionality of restoreStatOnFile may be reused. Move it into
FileUtilities.cpp. Create helper class FilePermissionsCarrier
to store and apply permissions.

Diff Detail

Event Timeline

avl created this revision.Apr 14 2022, 1:35 PM
avl requested review of this revision.Apr 14 2022, 1:35 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 14 2022, 1:35 PM
MaskRay added a comment.EditedApr 14 2022, 2:31 PM

Functionality of restoreStatOnFile may be reused.

Do you have an impending usage? The functionality is to emulate in-place update of GNU strip/objcopy where "copy" in "objcopy" assumes some "cp" like behavior. This somewhat makes replacing GNU strip/objcopy easy.

For many utilities, they probably shouldn't do this.

llvm/include/llvm/Support/FileUtilities.h
127

private?

avl added a comment.Apr 14 2022, 3:01 PM

Functionality of restoreStatOnFile may be reused.

Do you have an impending usage? The functionality is to emulate in-place update of GNU strip/objcopy where "copy" in "objcopy" assumes some "cp" like behavior. This somewhat makes replacing GNU strip/objcopy easy.

For many utilities, they probably shouldn't do this.

I would like to use it for the new utility - https://reviews.llvm.org/D86539#inline-1182993 . I think it would be good if the behavior would match with "objcopy". f.e. this utility might be used instead of

`llvm-objcopy` --only-keep-debug in-file out-file.debug
`llvm-objcopy` --strip-debug in-file out-file
`llvm-objcopy` --add-gnu-debuglink=out-file.debug out-file

Mostly looks fine to me. Just a couple of points/questions.

llvm/include/llvm/Support/FileUtilities.h
114–115
117

I wonder if FilePermssionsApplier might make it clearer why this isn't just a POD type (and more importantly why it isn't just a copy of sys::fs::perms?

llvm/lib/Support/FileUtilities.cpp
341

Why do you need this extra layer here and not just do the check in the other apply function?

avl added inline comments.Apr 19 2022, 12:51 AM
llvm/lib/Support/FileUtilities.cpp
341

I thought about adding other variants of interface methods. Like

apply(StringRef OutFileName);

In this case there would be several interface methods with different arguments and single internal method used to implementation.

but finally decided to have single universal interface method. So we can remove extra layer in this version of the patch.

avl added inline comments.Apr 19 2022, 12:58 AM
llvm/include/llvm/Support/FileUtilities.h
117

sorry, did not get the second part of question. The FilePermissionsCarrier/FilePermssionsApplier already contains a copy of permissions:

sys::fs::file_status InputStatus;

What do you suggest to change?

avl updated this revision to Diff 423872.Apr 20 2022, 4:46 AM

addressed comments.

jhenderson accepted this revision.Apr 22 2022, 2:17 AM

LGTM, once the name typo has been fixed.

llvm/include/llvm/Support/FileUtilities.h
117

Sorry, realised I made a couple of typos in my original comment.

FilePermssionsApplier -> FilePermissionsApplier

The name change was the only thing I was requesting. The rest of the comment was about why I recommended it:

  1. It's not a POD type but "Carrier" implies it just stores some data.
  2. The class is needed because it also does something to the data it is storing. We can't just use sys::fs::perms or similar directly because of this.
This revision is now accepted and ready to land.Apr 22 2022, 2:17 AM
avl added a comment.Apr 22 2022, 3:02 AM

Thank you for the review.

llvm/include/llvm/Support/FileUtilities.h
117

Ah, I see. thanks.