This is an archive of the discontinued LLVM Phabricator instance.

[lld-macho] Implement -oso_prefix
ClosedPublic

Authored by oontvoo on Oct 21 2021, 7:39 PM.

Diff Detail

Event Timeline

oontvoo created this revision.Oct 21 2021, 7:39 PM
Herald added a project: Restricted Project. · View Herald Transcript
Herald added a reviewer: Restricted Project. · View Herald Transcript
Herald added a subscriber: dang. · View Herald Transcript
oontvoo requested review of this revision.Oct 21 2021, 7:39 PM
Herald added a project: Restricted Project. · View Herald TranscriptOct 21 2021, 7:39 PM
oontvoo updated this revision to Diff 381464.Oct 21 2021, 8:13 PM

remove fixme

thevinster added inline comments.Oct 22 2021, 1:09 AM
lld/MachO/Driver.cpp
1100

I wasn't able to find where ld64 did this transformation. In fact, I don't see ld64 doing any transformation for the prefix. It looks like it just strips from the debug path if it has the raw prefix. That said, it seems nice to have this extra functionality for LLD. Do you know if real_path also expands .. as well?

1101

Just wondering, how did you come up with 128? Realistically speaking, I haven't seen prefixes that will that much space, but I guess it's possible to have really ugly nested directories on some systems out there....

1102

nit: You can drop the llvm::sys::. It seems to be namespaced already.

lld/MachO/SyntheticSections.cpp
864

Even if it were empty, wouldn't calling consume_front be harmless?

thakis accepted this revision.Oct 22 2021, 7:26 AM
thakis added a subscriber: thakis.

Looks generally fine to me.

Do you think we could test ~ expansion by running a test with env HOME=/some/custom/path?

lld/MachO/Driver.cpp
1105

s/backslash/slash/

This revision is now accepted and ready to land.Oct 22 2021, 7:26 AM
int3 added a subscriber: int3.Oct 22 2021, 9:46 AM
int3 added inline comments.
lld/MachO/Driver.cpp
1100

if ld64 isn't doing it, I would prefer we not add extra logic to LLD just because :)

1101

We've been using 261 for similar things in the codebase, because the max filename length on Windows is 260. Max filename length on Linux is 255, but max *path* length is 4096, so I guess to be really safe some of these path strings should have 4096 bytes allocated...

lld/test/MachO/stabs.s
80

nit: can we keep the columns aligned? maybe call this REL-DOT

oontvoo updated this revision to Diff 381595.Oct 22 2021, 10:30 AM
oontvoo marked 2 inline comments as done.

addressed comments

lld/MachO/Driver.cpp
1100

LD64 doesn't expand anything other than the .
But IMO, that seems weird to handle only one special notation and not the others . I think we should just use real_path to do it - and if it happens to be able to do more transformations than LD64 then so be it. I can't think of a reason why someone would pass ~, for eg., and not expect it to be expanded - especially given that the path we emit to stabs never contains these special characters anyway.

1101

The 128 originally came from copy-and-paste - I'd have thought it should be plenty for most cases.

Ok, yakshaving here :) , but isn't 4096 too much (if the prefix is 4096 ie., max length, then you're trimming everything, no?)
How about 512? (based on slightly unscientific observation that the top 10 longest paths in lld-macho's test output are 253 to 266 chars long, on my machine)

 vyng@vyng:/mnt/ssd/repo/llvm-project/build_lld$ ls -R /mnt/ssd/repo/llvm-project/build_lld | awk '
/:$/&&f{s=$0;f=0}
/:$/&&!f{sub(/:$/,"");s=$0;f=1;next}
NF&&f{ print s"/"$0 }' | awk '{print length, $0}' | sort -nr | head -n10
266 /mnt/ssd/repo/llvm-project/build_lld/tools/lld/test/MachO/Output/reroot-path.s.tmp/repro6/mnt/ssd/repo/llvm-project/build_lld/tools/lld/test/MachO/Output/reroot-path.s.tmp/mnt/ssd/repo/llvm-project/build_lld/tools/lld/test/MachO/Output/reroot-path.s.tmp/libfoo.dylib
266 /mnt/ssd/repo/llvm-project/build_lld/tools/lld/test/MachO/Output/reroot-path.s.tmp/repro6/mnt/ssd/repo/llvm-project/build_lld/tools/lld/test/MachO/Output/reroot-path.s.tmp/mnt/ssd/repo/llvm-project/build_lld/tools/lld/test/MachO/Output/reroot-path.s.tmp/libbar.dylib
266 /mnt/ssd/repo/llvm-project/build_lld/tools/lld/test/MachO/Output/reroot-path.s.tmp/repro5/mnt/ssd/repo/llvm-project/build_lld/tools/lld/test/MachO/Output/reroot-path.s.tmp/mnt/ssd/repo/llvm-project/build_lld/tools/lld/test/MachO/Output/reroot-path.s.tmp/libbar.dylib
266 /mnt/ssd/repo/llvm-project/build_lld/tools/lld/test/MachO/Output/reroot-path.s.tmp/repro4/mnt/ssd/repo/llvm-project/build_lld/tools/lld/test/MachO/Output/reroot-path.s.tmp/mnt/ssd/repo/llvm-project/build_lld/tools/lld/test/MachO/Output/reroot-path.s.tmp/libbar.dylib
266 /mnt/ssd/repo/llvm-project/build_lld/tools/lld/test/MachO/Output/reroot-path.s.tmp/repro3/mnt/ssd/repo/llvm-project/build_lld/tools/lld/test/MachO/Output/reroot-path.s.tmp/mnt/ssd/repo/llvm-project/build_lld/tools/lld/test/MachO/Output/reroot-path.s.tmp/libbar.dylib
259 /mnt/ssd/repo/llvm-project/build_lld/tools/lld/test/MachO/Output/reroot-path.s.tmp/repro2/mnt/ssd/repo/llvm-project/build_lld/tools/lld/test/MachO/Output/reroot-path.s.tmp/mnt/ssd/repo/llvm-project/build_lld/tools/lld/test/MachO/Output/reroot-path.s.tmp/bar.a
259 /mnt/ssd/repo/llvm-project/build_lld/tools/lld/test/MachO/Output/reroot-path.s.tmp/repro1/mnt/ssd/repo/llvm-project/build_lld/tools/lld/test/MachO/Output/reroot-path.s.tmp/mnt/ssd/repo/llvm-project/build_lld/tools/lld/test/MachO/Output/reroot-path.s.tmp/bar.a
253 /mnt/ssd/repo/llvm-project/build_lld/tools/lld/test/MachO/Output/reroot-path.s.tmp/repro6/mnt/ssd/repo/llvm-project/build_lld/tools/lld/test/MachO/Output/reroot-path.s.tmp/mnt/ssd/repo/llvm-project/build_lld/tools/lld/test/MachO/Output/reroot-path.s.tmp
253 /mnt/ssd/repo/llvm-project/build_lld/tools/lld/test/MachO/Output/reroot-path.s.tmp/repro5/mnt/ssd/repo/llvm-project/build_lld/tools/lld/test/MachO/Output/reroot-path.s.tmp/mnt/ssd/repo/llvm-project/build_lld/tools/lld/test/MachO/Output/reroot-path.s.tmp
253 /mnt/ssd/repo/llvm-project/build_lld/tools/lld/test/MachO/Output/reroot-path.s.tmp/repro4/mnt/ssd/repo/llvm-project/build_lld/tools/lld/test/MachO/Output/reroot-path.s.tmp/mnt/ssd/repo/llvm-project/build_lld/tools/lld/test/MachO/Output/reroot-path.s.tmp
oontvoo updated this revision to Diff 381597.EditedOct 22 2021, 10:36 AM
oontvoo marked an inline comment as not done.

typo + rebase again( seems parallel-libs has been removed - why is it still being referenced?)

CMake Error at CMakeLists.txt:76 (MESSAGE):
  parallel-libs isn't a known project:
  clang;clang-tools-extra;compiler-rt;cross-project-tests;libc;libclc;libcxx;libcxxabi;libunwind;lld;lldb;mlir;openmp;polly;pstl;flang
oontvoo updated this revision to Diff 381600.Oct 22 2021, 10:47 AM

adding test with env HOME=/some/custom/path

int3 accepted this revision.Oct 22 2021, 11:58 AM

lgtm

lld/MachO/Driver.cpp
1100

Gotcha. Yeah, if we have to handle ".", it makes sense to use real_path and handle all the cases. Worth leaving a comment here that ld64 only handles "." though.

1101

what's 4k bytes between friends? :p

yeah, looking at the codebase, I see there are a bunch of SmallString<128>s, but also 260s and 261s...

feel free to put whatever here; I think I'll codemod them to something more consistent later

lld/MachO/SyntheticSections.cpp
864

worth addressing

lld/test/MachO/stabs.s
80

don't forget about this :)

thevinster accepted this revision.Oct 22 2021, 12:20 PM
thevinster added inline comments.
lld/MachO/Driver.cpp
1100

I did a quick test and it looks like the apple provided ld64 does seem to work with ~ and ., but a "built-from-source" ld64 won't work with it.

$ cat main.c
main(){}
$ clang -c -g main.c
$ clang -fuse-ld=<path-to-internally-built-ld64> -o a.out -Wl,-oso_prefix,. -g main.o
$ clang -o b.out -Wl,-oso_prefix,. -g main.o
$ nm -a a.out | grep OSO
0000000061730ca3 - 03 0001   OSO /Users/leevince/sandbox/test2/main.o
$ nm -a b.out | grep OSO
0000000061730ca3 - 03 0001   OSO main.o

I don't know where this leaves us, but it's probably fine as is written here.

oontvoo requested review of this revision.Oct 22 2021, 1:11 PM
oontvoo marked 6 inline comments as done.
oontvoo added inline comments.
lld/MachO/Driver.cpp
1100

if you invoke the linker from the clang driver, I suspect this ~ is expanded by the shell (or possibly clang) and not ld64.
invoking LD64 directly (and from looking at the its code), it doesn't expand ~ at all :

$  ld -arch x86_64 -platform_version macos 10.15 11.0 -syslibroot /Users/vyng/repo/llvm/llvm-project/lld/test/MachO/Inputs/MacOSX.sdk -fatal_warnings -lSystem test.o foo.o no-debug.o -oso_prefix "~" -o /Users/vyng/repo/llvm/llvm-project/build_lld/tools/lld/test/MachO/Output/stabs.s.tmp/test-rel-tilde     
vyng-macbookpro2 /Users/vyng/repo/llvm/llvm-project/build_lld/tools/lld/test/MachO/Output/stabs.s.tmp$ nm -a test-rel-tilde| grep 'OSO'
0000000000000020 - 03 0001   OSO /Users/vyng/repo/llvm/llvm-project/build_lld/tools/lld/test/MachO/Output/stabs.s.tmp/foo.o
0000000000000010 - 03 0001   OSO /Users/vyng/repo/llvm/llvm-project/build_lld/tools/lld/test/MachO/Output/stabs.s.tmp/test.o
lld/MachO/SyntheticSections.cpp
864

done - forgot to update

oontvoo updated this revision to Diff 381643.Oct 22 2021, 1:11 PM
oontvoo marked 2 inline comments as done.

addressed previously missed comments.

The windows build is red but it doesn't look related ... committing now.
Thanks for the review!

This revision was not accepted when it landed; it landed in state Needs Review.Oct 22 2021, 1:33 PM
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.

This revision was not accepted when it landed; it landed in state Needs

Review.

This is soooo not true ! 🤔 I've got 3 LGTM