[llvm-bugs] [Bug 49800] New: Support $ld$ symbols

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=49800

            Bug ID: 49800
           Summary: Support $ld$ symbols
           Product: lld
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: MachO
          Assignee: unassignedbugs at nondot.org
          Reporter: smeenai at fb.com
                CC: gkm at fb.com, jezreel at gmail.com,
                    llvm-bugs at lists.llvm.org, smeenai at fb.com

There's a bunch of symbols prefixed with $ld$ that have special meaning to the
linker. The ones I could find:

$ld$hide$
$ld$add$
$ld$weak$
$ld$install_name$
$ld$compatibility_version$
$ld$previous$

All of these except $ld$previous$ have been around for quite some time, and
have the effects you would expect from their names. Apple's open source release
of tapi has code to handle them, as does ld64's dylib parser. The tapi in LLVM
does not appear to have code to handle them so far, as far as I can see.

$ld$previous$ is new in the ld64 609 source code release (corresponding to
Xcode 12). It seems to be able to override the install name of the entire
library or the install name that particular symbols are associated with. The
former functionality is used in Xcode 12.5's SDK for the newly introduced
AVFAudio framework; its install name is overridden to AVFoundation if you're
targeting iOS 14.5 or newer. The following demonstrates this behavior:

$ cat use.s
        .long   _AVAudioBitRateStrategy_Constant at GOTPCREL

$ llvm-mc -filetype obj -triple x86_64-apple-ios14.0.0-simulator -o use.o use.s
$ ld -platform_version ios-simulator 14.0.0 14.5 -arch x86_64 -dylib \
    -o libuse.dylib use.o -framework AVFoundation \
    -syslibroot
/Applications/Xcode_12.5_beta_3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk 
$ objdump --macho --dylibs-used libuse.dylib
libuse.dylib:
        libuse.dylib (compatibility version 0.0.0, current version 0.0.0)
        /System/Library/Frameworks/AVFoundation.framework/AVFoundation
(compatibility version 1.0.0, current version 2.0.0)

$ llvm-mc -filetype obj -triple x86_64-apple-ios14.5.0-simulator -o use.o use.s
$ ld -platform_version ios-simulator 14.5.0 14.5 -arch x86_64 -dylib \
    -o libuse.dylib use.o -framework AVFoundation \
    -syslibroot
/Applications/Xcode_12.5_beta_3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk 
$ objdump --macho --dylibs-used libuse.dylib
libuse.dylib:
        libuse.dylib (compatibility version 0.0.0, current version 0.0.0)
        /System/Library/Frameworks/AVFoundation.framework/AVFoundation
(compatibility version 1.0.0, current version 2.0.0)
        /System/Library/Frameworks/AVFAudio.framework/AVFAudio (compatibility
version 1.0.0, current version 1.0.0)

In the first case, since our minimum version is < 14.5, the install name
override kicks in. In the second case, our minimum version is >= 14.5, so we
see AVFAudio in the dylibs list. Since LLD doesn't implement this, both cases
will add AVFAudio to the dylibs list right now, and we'll produce a binary that
can't be run on older OS versions.

Interestingly enough, $ld$previous$ is implemented in a centralized location in
ld64 (in its generic dylib parser, which is the base parser class for Mach-O
dylibs and TBDs), whereas the other symbols are separately implemented in ld64
and tapi. There's also a FIXME in ld64 609's source to issue warnings for the
other $ld$ symbols once $ld$previous$ is submitted and documented, so perhaps
the eventual plan is for $ld$previous$ to subsume the functionality of the
others and be the only one?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210401/afc5e9c7/attachment-0001.html>