llvm-strip breaks symlink

[pawelsopensource]

Please consider following shell testcase:

touch empty.c
clang empty.c -shared -o empty.so.1
ln -sf empty.so.1 empty.so
strip --strip-unneeded empty.so
[ -L empty.so ] || echo "KO1"
llvm-strip --strip-unneeded empty.so
[ -L empty.so ] || echo "KO2"

llvm-strip (15.0.6) breaks empty.so symlink and reports KO2. binutils strip works fine.

[llvmbot]

@llvm/issue-subscribers-tools-llvm-objcopy-strip

[chestnykh]

Candidate patch: https://reviews.llvm.org/D141145

[MaskRay]

I think we have made a decision (for crbug.com/1108880 c2a8477 @manojgupta) that we always create a new file instead of reusing the existing file. This is more in line with most other llvm-* clang* utilities which may create an output file (and gcc, as, etc, but not cp).
It can be argued that our behavior has stronger security characteristics since it doesn't follow a symlink (see https://sourceware.org/bugzilla/show_bug.cgi?id=26945 ).
Perhaps we should just accept this incompatibility with GNU objcopy. This normally isn't an issue for users.

The binutils behavior of following symlinks and doing smart_rename is quite complex.

[chestnykh]

@MaskRay So this issue is not a bug and then i close the review?

[MaskRay]

@MaskRay So this issue is not a bug and then i close the review?

I think so but you may wait a bit for more feedback.

[pawelsopensource]

imho, breaking devel symlinks (foo.so -> foo.so.x -> foo.so.x.y) by simple llvm-srip foo.so* should be reported as an error. in the current state compiler/linker/runtime-loader may pick different files after "foo upgrade"

[chestnykh]

I think this is not very critical if llvm-strip will break symlink and create regular file instead, but such behaviour may cause negative side-effects for example in someone scripts which expect a symlink but instead we provide regular file

[brad0]

This normally isn't an issue for users.

Build infrastructure are users.

We tried switching over to llvm-strip to deal with an issue we are having with GNU strip and ran into this issue which broken building our ports / packages.

The old strip replaces the contents of the file.
llvm-strip moves a new file into place, breaking hard links.

This shows up when fake creates hard links to a binary and the
DEBUG_PACKAGES infrastructure runs strip during packaging.
The problem is caught as PLIST changes involving @link if you
build with PLIST_DB.

CVSROOT:	/cvs
Module name:	src
Changes by:	kettenis@cvs.openbsd.org	2023/01/18 17:18:19

Modified files:
	gnu/usr.bin/binutils-2.17: Makefile.bsd-wrapper 
	gnu/usr.bin/clang/llvm-objcopy: Makefile 
Added files:
	gnu/usr.bin/clang/llvm-objcopy: strip.1 

Log message:
The binutils strip damages GNU_RELRO on binaries linked by ld.lld on at
least amd64.  Fix this by switching to the llvm strip on architectures
that use ld.lld.

CVSROOT:	/cvs
Module name:	src
Changes by:	kettenis@cvs.openbsd.org	2023/01/19 15:54:45

Modified files:
	gnu/usr.bin/binutils-2.17: Makefile.bsd-wrapper 
	gnu/usr.bin/clang/llvm-objcopy: Makefile 

Log message:
Revert previous commit (but leave the man page around); llvm-strip behaves
differently on files that are hardlinked and this is tripping up ports.

[brad0]

CVSROOT:	/cvs
Module name:	src
Changes by:	kettenis@cvs.openbsd.org	2023/01/27 15:01:02

Modified files:
	gnu/usr.bin/clang/llvm-objcopy: Makefile 
	gnu/usr.bin/binutils-2.17: Makefile.bsd-wrapper 

Log message:
Recommit the switch to use llvm-strip on architectures that use ld.lld.

The part that needed a workaround in ports..

openbsd/ports@9a85588