[WWDC19] LLDB: Beyond "po"

LLDB 는 앱 런타임 중에 디버깅 할 수 있는 툴이다.

"po"

기본적으로 LLDB 에서 po ~~ 명령어를 작성하면 해당 타입과 프로퍼티에 대해 보여준다.

CustomDebugStringConvertible 프로토콜을 채택하고, debugDescription 을 추가하면 Object 이름이 나타나는 곳에 커스텀하게 설명을 추가할 수 있다.

• Sub structure 에 대한 커스텀이 필요하다면 CustomReflectable 을 찾아보자.

po 명령어는 객체를 프린팅하는 것 외에도, 메소드 호출 등의 동작을 할 수 있다.

po 는 사실 특정 명령어를 alias 로 단축시킨 것이다. 다른 이름으로 동일하게 만들 수도 있다.

• expression --object-description 을 줄인것

"po" Under the Hood

(lldb) po view 가 실행되는 과정을 봅시다

• LLDB 는 스스로 파라미터를 파싱하거나 코드를 실행시키지 않는다.
• po 명령어를 입력하면 컴파일이 가능한 소스코드를 생성한다.
  

  

• 컴파일러가 소스코드를 컴파일한 다음, 실행한다.
• 실행이 완료된 후 LLDB 는 결과 값에 액세스하고, description 을 가져와 소스 코드로 래핑한다.
  

  

• 위의 소스 코드는 디버그 프로세스에 의해 컴파일 후 실행된다.
  

  

• 위의 실행 결과는 LLDB 가 po 명령의 결과로 표시할 문자열이다.
  

  

po 는 LLDB 에서 변수를 프린팅하는 세가지 중 첫번째 방법일 뿐이다.

"p"

p 명령은 객체에 대한 설명이 없이 출력하는 명령어이다.

• po 와 비교했을 때, 객체에 대한 정보를 출력하는 점은 같지만
• 객체 타입명 대신 $R0 으로 나타나는 점이 다르다.

p cruise 의 결과인 $R0 에 대해서 또 명령을 실행하면, 다음 결과는 $R1, $R2 로 나타난다.

• 레지스터에 저장되는 값이 아닐까 🤔

p 연산은 expression 에 대한 alias 로, po 명령에서 옵션이 없는 버전이다.

• po == expression --object-description

"p" Under the Hood

(lldb) p cruise 를 실행했을 때, 소스 코드를 실행하고, 컴파일 ~ 결과를 보여주는 부분까지는 po 와 동일하다.

결과를 얻은 후에 Dynamic type resolution 단계에서 동적 타입으로의 캐스팅을 한다.

 

아래 예제처럼 컴파일시 정적 타입과 런타임시 동적 타입이 달라지는 경우,

• 정적 타입인 Activity 로 인식하면 프로퍼티에 접근이 불가능
• 동적 타입인 Trip 으로 컨버팅 한 이후에 프로퍼티에 접근이 가능
  

  

p cruise.name 처럼 바로 동적 타입의 프로퍼티에 대해 접근하려고 하면 오류가 난다.

• 컴파일이 된 이후에 동적 타입으로 변경되는 것이기 때문에, 명령어 실행 시점에는 정적 타입만 알고 있다.
• 이부분은 소스코드에서도 동일하다. 바로 사용하고 싶다면 명시적으로 캐스팅을 작성해라.

이후 LLDB 는 결과를 Formatter 에게 전달해서, 사람이 읽기 좋은 형태로 변환한다.

Formatter 를 통하지 않고 raw 데이터를 본다면 다음과 같다.

"v"

v 명령의 출력은 p 와 동일한 Formatter 를 거치기에 동일하다.
코드를 컴파일하고 실행하는 과정이 없기 때문에 매우 빠르다.

"v" Under the Hood

v 명령은 program state 를 참조해서, 메모리에서 변수를 찾는다.
메모리에서 변수 값을 읽고, 동적 타입 변환을 한다.

만약 프로퍼티에 대한 접근이 필요하다면, 다시 메모리에서 읽고 동적 타입 변환을 반복한다.
이후 Formatter 에게 전달해 결과를 변환한다.

p 명령과 다르게 v 명령은 동적 타입의 프로퍼티에 대해 바로 접근이 가능하다.

Displaying Variables

 

Customizing Data Formatter

LLDB 의 Data Formatter 는 확장 가능하다. 😮

 

Trip 객체를 출력할 때, filter 를 추가해서 name 만 출력하도록 할 수 있다.

객체의 summary 를 추가할 수 있다. 변수는 ${var} 로 묶어준다.

• Formatter 는 배열의 개수를 알 수 없기 때문에, 아래의 동작은 destinations[0] 처럼 직접 하드코딩 해야한다는 단점이 있다.

Python Formatter

Python Formatter 를 통해 연산을 할 수 있고, LLDB Scripting Bridge API 에서 제공하는 객체를 통해 현재 디버깅중인 세션에 접근할 수 있다.

 

(lldb) script 를 통해 python 3 를 실행시킬 수 있고, 인터프리터가 제공된다. 데이터가 보여지는 형식은 기존 Data formatter 와 동일하다.

위의 예제에서 LLDB API 에서 제공되는 메소드를 통해 인덱스를 가져오도록 변경해서, 인덱스 하드 코딩을 이겨낼 수 있다! 🥹

 

.py 파일에 코드를 작성하고 임포트해서, type summary 로 지정해 사용할 수 있다.

 

객체에 대한 프로퍼티는 SB value 를 갖고, 각각에 대한 summary 를 갖는다.

• summary 를 지정하는 건 비슷하지만, 특정 메소드를 갖는 클래스를 정의해야 한다.
• child 에 대한 설명을 커스텀할 때에는 type synthetic 명령어를 사용한다.

~/.lldbinit 파일에 명령어를 저장해두면, 디버그 세션이 시작될 때 자동으로 로드된다.

Summary

• v, p, po 를 통해 변수를 출력하자 🙆‍♀️
• filter, summary, synthetic children 을 통해 데이터 포맷을 커스터마이징하자 👀
• 스크립트에 Python 3 를 사용하자.... 🙄