• Synbolication이란? 앱 런타임(메모리 주소, 명령어 등)을 소스 코드(함수, 이름, 파일)에 매핑하는 것
• 예제 프로그램

func selectMagicNumber(choices: [Int]) -> Int {
	return choices[MAGIC_CHOICE]
}

func randomValue() -> Int {
	return Int.random(in: 1...100)
}

func numberChoices() -> [Int] {
	var choices = [Int]()
	for _ in 1...10 {
		choices.append(randomValue())
	}

	return choices
}

func generateMagicNumber() -> Int {
	let numbers = numberChoices()
	let magic = selectMagicNumber(choices: numbers)
	return magic
}

print("The magic number is: \\(generateMagicNumber())")

• 여기서 크래시가 났다.

  • 첫번째로는 크래시 로그를 봐야 한다. 근데 이것만으로는 어디선가 크래시가 났다는 것 이상으로는 뭐를 알기 힘들다.
    • 레지스터 정보가 뜨긴 하는데, 이게 뭔지 어떻게 알아
    • 재현 가능하면 디버거로 해볼텐데 재현이 안된다면?
  • 디스어셈블을 해볼 수도 있지만, 더 어렵고 별 도움이 안될 가능성이 높다.
  • 하지만 Symbolication이 있다면 좀 더 쉽게 시작할 수 있다.
    • 실행된 함수, 파일, 이름을 쉽게 확인 할 수있다.

• Symbolication 하기

  • Xcode Organizer에서 보기
  • atos 커맨드: dSYM이 이미 있을 때

• Instrument도 symbolication을 활용해서 좀 더 풍부한 정보를 보여줄 수 있다.

• 질문할 것들

  • 어떻게 동작하는가?
    • 다양한 빌드 및 디버깅 툴들이 symbolication위에서 동작한다.
    • atos 커맨드를 쓰면 크래시 원인을 파악할 수 있다.
      • 플래그들이 어떻게 동작하는가?
    • 왜 심볼이 제대로 안되는가?
    • 빌드세팅 적용하기
  • 어디에 적용할 수 있는가?
  • dSYM만 있으면 끝인가?

• Symbolication 프로세스

  • 파일로 돌아가기
    • 목표: 런타임 주소를 파일 주소로 변환하는것
    • 앱은 디스크에서도 주소공간을 가지는데, 런타임 주소와 이 두가지의 차이를 알아야 한다.
    • 디스크에서의 주소 공간
      • 링커에 의해 할당됨
      • 링커는 파일을 세그먼트로 그룹화
      • 각 세그먼트는 여러가지 데이터와 프로퍼티를 가진다.(이름, 사이즈, 할당된 주소 등)
      • 세그먼트 예시
        • 텍스트: 함수, 메소드 등
        • 데이터: 전역 변수 등
      • 이 세그먼트 프로퍼티들은 Mach-O 헤더에 기록된다.
        • 세그먼트를 불러오기 위한 Load 커맨드 갯수
        • Universal 2 바이너리면 아키텍쳐마다 헤더가 있다.
      • otool로 분석할 수 있다.
        • Load 커맨드에는 로딩하는 세그먼트 이름, 시작 주소, 사이즈가 있다.
        • 로딩될 때 시스템은 랜덤한 값 S(ASLR Slide)를 만들어서, 디스크 주소에 더한다. 이렇게 더해진 주소를 시스템이 실제로 사용하게 된다.
        • 즉, 시스템이 보는 주소에서 ASLR을 빼면 파일 주소가 나오고, 반대로 시스템 주소에서 파일 주소를 빼면 ASLR값을 구할 수도 있다.
        • 파일 주소는 링커로 부터 알 수 있고, 메모리에 로딩된 주소값은 실제 돌아가고 있는 프로세스로 부터 구할 수 있다.
          • 이는 크래시 로그에 딸려온 바이너리 이미지 리스트에 포함되어 있다.
          • vmmap툴을 이용하면 인터렉티브하게 볼 수도 있다.
      • atos 플래그
        • -o: 파일의 세그먼트 주소
        • -l: 로드 주소. 인라인을 고려함
      • 교훈
        • 모든 런타임 주소는 ASLR을 통해서 파일 주소로 매핑될 수 있다.
        • 이 파일 주소를 통해서 디버그 정보로 활용할 수 있다.
  • 디버그 정보 컨설팅

    • 디버그 정보는 빌드 과정에서 생성된다.

    • 바이너리에 임베딩 될 수 도 있고, 별도 파일로 존재할 수도 있다.

    • 종류

      • 함수 시작점: 함수 주소만 있음
        • 가장 간략한 정보
        • __LINKEDIT 세그먼트에 임베딩 되어 있다.
          • LC_FUNCTIN_STARTS로 표현
          • 크래시 난 지점이 어떤 곳인지 특정할 수 있음 → 다만 이름은 없다.
      • Nlist 심볼 테이블: 함수 주소와 함수 이름
        • 역시 __LINKEDIT 세그먼트에 인코딩되어 있다.
        • 다만 단순 주소값은 아니고 C구조체다.

      struct nList_64 {
      	union {
      		uint32_t n_strx;
      	}
      	
      	uint8_t n_type; // 값과 프로퍼티를 결정하는 값
      	uint8_t n_sect;
      	uint16_t n_desc;
      	uint64_t n_value;
      }
      

      • type은 여러개가 있지만, 그 중 일부만 살펴보자
        • direct symbol: 앱과 프레임워크에 완전히 정의되어 있는 심볼. 이름과 주소값을 가진다.

          • 이 때 이름은 mangle된 상태로 기록된다.

          • 2,3,4번째 LSB가 켜져 있는 상태로 표현

            • 이는 N_SECT라고도 알려져 있다.

          • 심볼 리스팅

            % nm -arch arm64 -defined-only --numeric-sort MagicNumbers | xcrun swift-demangle
            
            % symbols -arch arm64 -onlyNListData MagicNumbers // 자동으로 디맹글링
            
            

          • 다만 링킹에 연관된 정보만 있다. 이는 프로젝트 전체적으로 공유되는 컴포넌트, 프레임워크에서 export된 심볼들이 해당한다.

          • 로컬, 정적 함수들은 테이블에서 표현되지 않고, 관련 심볼 정보는 릴리즈모드에서 앱 사이즈 감소등의 이유로 날리는 경우도 있다. → Deployment에 Strip관련 옵션 존재

            • Strip Linked Product(Bool): 스트립 할까 말까?
            • Strip Style: 어떤 걸 스트립할까?
              • All Symbol: 필수적인 거 빼고 전부
              • Non Global: 로컬 공유 함수 제거
              • Debugging Symbol: 다이렉트 심볼만 nlist테이블에 남기고 스트립
        • indirect symbol
          • LSB만 켜져 있는 형태로, N_EXT 패턴으로 알려져 있다.
          • 의존성에 의해 제공되는 심볼들
      • DWARF( dSYM, 정적 라이브러리): 위에 더해 파일과 라인 번호,. 최적화 정보 등도 제공
        • 매우 디테일하고 풍부한 표현식
        • 함수 간의 호출 연관 관계를 표현함
        • 주로 dSYM bundle에서 확인 가능.
        • DWARF가 포함된 바이너리
          • _DWARF 세그먼트를 추가로 가짐
            • raw data(debug_info), raw_data의 구조(debug_abbrev) , 파일 이름과 라인 번호(debug_line)를 포함한다.
          • 추가적으로 3개의 vocabulary types을 가짐
            • Compile unit
              • 소스파일 하나를 표현
              • 파일 이름, SDK 이름, __ TEXT 세그먼트에서 사용하는 영역 등의 프로퍼티가 할당됨
            • Subprogram
              • 정의된 함수나 메소드
              • nilist에서 다루지 못했던 로컬 혹은 정적 함수도 다루고 있다.
              • Compile Unit 안에서 정의되고, DWARF는 이를 트리 구조로 표현. 이 안에서 range로 서치 가능
            • inlined subrouties
              • 인라인된 함수를 나타내기 위한 타입
              • 다른 subprogram안에 인라인된 subprogram
              • 인라인된 함수의 자식으로 표현됨
              • 다른 자식을 인라이닝할 수 있음
        • dwarfdump 프로그램으로 dSYM을 dump뜰 수 있다.
      • 파일 이름과 라인 넘버
        • debug_line을 통해서 들어온다.
        • 트리 구조 가 아니라 line table program을 구성함 → 주소를 가지고 라인 번호로 매핑한다.
        • 주소와 소스 위치의 정렬된 리스트를 만들어낸다.
  • 정적 라이브러리와 Object 파일에서도 dSYM을 찾을 수 있다.

• Tools and Tips

  • 디버그 모드에서는 DWARF를 마음껏 써라

  • 릴리즈에서는 DWARF with dSYM File옵션을 켜라

  • 엡스토어 커넥트에서 dSYM을 받을 수도 있다.

  • 로컬 dSYM 찾기

    

  • DWARF 검증하기

    

  • DWARF는 4GB 제한이 있기 때문에, 이만큼 커질 것 같으면 컴포넌트로 쪼개라

  • dSYM이 어떤 빌드의 것인지 검증하기