OS X의 취약 기호 별칭은 Linux와 유사하거나 이에 준하는 것입니까?
내가 하는 일
Linux용 공유 라이브러리를 작성할 때는 재배치, 심볼 가시성, GOT/PLT 등에 주의를 기울이는 경향이 있습니다.
해당하는 경우, 같은 라이브러리의 함수가 서로 호출할 때 PLT 스터브 호출을 피하려고 합니다.예를 들어 공유 객체가 두 가지 공용 기능을 제공한다고 가정해 보겠습니다.foo()
그리고.bar()
(둘 다 사용자가 호출할 수 있습니다).그bar()
단, 이 함수도 호출합니다.foo()
이 경우 제가 하는 일은 다음과 같습니다.
- 정의
_foo()
그리고._bar()
프라이빗 가시성이 있는 기능. - 정의
foo()
그리고.bar()
에 대한 약한 가명_foo()
그리고._bar()
각각 다음과 같다.
이렇게 하면 공유 객체의 코드는 약한 기호를 사용하지 않습니다.로컬 기능만 직접 호출합니다.예를 들어,_bar()
호출되어 호출됩니다._foo()
직접적으로.
그러나 사용자는 다음 사항을 인식하지 못합니다._*
항상 대응하는 약한 에일리어스를 사용합니다.
어떻게 하는 방법
Linux 에서는, 다음의 구조를 사용해 이것을 실현합니다.
extern __typeof (_NAME) NAME __attribute__(weak, alias("_NAME"));
문제
유감스럽게도 OS X에서는 동작하지 않습니다.OS X나 그 바이너리 포맷에 대해서는 잘 모르기 때문에, 조금 조사해 보니, 약한 기능의 몇개의 예(이 예와 같음)가 있었습니다만, 이러한 예에서는, 약한 기호는 그다지 사용할 수 없지만, DSO의 로컬 기능의 에일리어스인 약한 기호는 사용할 수 없습니다.
가능한 해결 방법...
현재는 매크로를 사용하여 구현되는 이 기능을 비활성화하여 모든 기호가 글로벌하고 기본 표시되도록 했습니다.지금으로서는 같은 목표를 달성하기 위해 생각할 수 있는 유일한 방법은_foo
개인 가시성을 가진 기능 및 대응하는 기능foo
기본 가시성을 가진 함수와 "숨겨진" 함수를 호출합니다.
더 좋은 방법?
그러나 그러기 위해서는 많은 코드 청크를 변경해야 합니다.그래서 나는 정말 다른 방법이 없는 한 그곳에 가고 싶지 않다.
그럼 closes OS X의 대체 방법 또는 동일한 의미와 동작을 얻기 위한 가장 쉬운 방법은 무엇일까요?
OS X 에서는, 라이브러리내에서 발신되는 콜은 자동적으로 다이렉트 콜이며, dyld stub 를 경유하지 않습니다.콜을 처리하기 위해 대체 함수를 삽입할 수 있는 경우 인터포저블을 사용하여 심볼에 간접적으로 접근하고 dyld stub을 통해 콜을 강제로 실행해야 한다는 것이 이 사실을 증명하는 증거입니다.그렇지 않으면 기본적으로는 로컬콜이 직접적이기 때문에 dyld를 통해 실행되는 오버헤드가 발생하지 않습니다.
따라서 Linux에서의 최적화는 이미 기본 동작이며 에일리어스는 필요하지 않습니다.
그러나 플랫폼 호환 코드를 단순화하기 위해 이 작업을 수행하는 경우에도 에일리어스를 만들 수 있습니다.속성명으로 "weak_import" 또는 "weak"(통합할 경우)를 사용하면 됩니다.
외부 유형(_NAME) NAME __속성(weak_import, alias("_NAME"));
취약링크에 관한 Apple 레퍼런스: 취약링크에 대한 마킹 기호
Mach-O 런타임 바인딩에 관한 Apple 참조: 기호 정의의 범위와 처리
언급URL : https://stackoverflow.com/questions/18260207/weak-symbol-aliases-on-os-x-similar-to-those-on-linux-or-a-closest-equivalent
'programing' 카테고리의 다른 글
네임슬레이드 모듈의 mapState 및 mapMutations 사용 (0) | 2022.07.15 |
---|---|
vue watcher에서 구성 요소 인스턴스 액세스 (0) | 2022.07.15 |
ctypes를 사용하여 Python 목록을 C 배열로 변환하려면 어떻게 해야 합니까? (0) | 2022.07.15 |
v-for에서 요소의 반복을 제한하는 방법 (0) | 2022.07.15 |
Spring Boot REST 서비스 예외 처리 (0) | 2022.07.08 |