Rust: 트레이 트 객체의 디버그 표현 추가

트레이 트의 디버그 표현은 무엇입니까? 나는 Trait을 런타임에 도달 할 때 지워지는 순전히 컴파일 타임 엔티티라고 생각합니다.

@jdm 이것은 @Trait 객체를위한 것입니까?

예, 특성 개체 (~ 및 @ 다양성)를 포함하도록 범위를 지정하는 것이 좋습니다.

middle/trans/debuginfo.rs 에 따르면 : cx.sess.span_note(span, "debuginfo for trait NYI");

즉, 이것은 여전히 ​​유효하고 적절하게 태그가 지정되고 이정표가 지정됩니다 (2013-06-19).

분류 방문; @michaelwoerister로 연기합니다.

분류 방문; @michaelwoerister로 연기합니다.

여전히 NYI이지만 이번 달 언젠가 다루어야합니다.

최신 정보:

PR # 9168부터 특성 개체에 대한 몇 가지 기본 지원이 있습니다. 트레이 트 개체 포인터는 올바른 크기 (포인터 2 개)와 이름 ({sigil} {mutability} {trait name})이 올바른 구조체로 설명되며 올바른 네임 스페이스에 배치됩니다. 이 "팻 포인터"의 내부는 아직 더 이상 설명되지 않습니다. 빠진 것은 특성의 방법에 대한 설명입니다. 나는 그것들이 실제로 어떻게 구현되는지에 대해 충분히 알지 못합니다.

1.0이 아니라 높음

@michaelwoerister : 그런데 새로운 vtable 레이아웃은 [drop_glue, method, method2, method3, ...] 입니다. 나는 이것이 미래에 supertrait 메소드가 trait 객체에서 호출 가능하게 될 때 어떻게 든 바뀔 것이라고 확신합니다.

Fat 가 DST 구조체 인 Fat<Trait> 와 같은 개체를 가질 수 있기 때문에 DST에서는 더 복잡해졌습니다. 특성 객체에 대한 스텁 코드가 조금 더 깨졌지만 스텁 일 뿐이므로 수정하고 싶지 않습니다. 나는 거기에 FIXME를 남겼습니다.

분류 범프 : 현재 상태가 무엇인지 확실하지 않습니다.

여전히해야 할 일

다음을 수행 할 수 있습니다.
(1) 정의하는 메소드를 포함하는 각 특성에 대한 유형 설명을 작성하십시오. 아직 DWARF 표준에는 특성이 없으므로 DW_AT_interface 를 사용하는 것이 가장 합리적입니다. 하지만 DW_AT_struct 사용하면 C 지향 디버거와 더 잘 호환됩니다.

(2) 특성 포인터 ( &Trait 등)를 (*(), *OpaqueVTable<Trait>) 유형의 튜플로 설명합니다.

(3) 팻 포인터가 주어지면 포인터 값과 유형 정보를 사용하여 vtable을 인쇄하는 Python에서 사용자 지정 GDB / LLDB 명령을 구현합니다.

완벽하지는 않지만 현재 사용 가능한 수단으로 할 수 있습니다. vtable이 가리키는 함수의 심볼 이름은 트레이 트 개체의 실제 런타임 유형도 나타내야합니다.

디버그 정보가있는 빌드에서만 (즉, 릴리스 빌드가 아님) 매우 적은 양만

분류 : 여전히해야합니다. cc @Manishearth @tromey P-low

현재 P-low 및 P-medium

P- 매체 제거

나는 최근에 이것을 조금 조사했습니다. 내가하고 싶은 것은 :

• 방출되는 각 vtable을 설명하는 일부 DWARF를 방출합니다. 이것은의 VTABLE의 위치, 그 vtable에 의해 표현 콘크리트 종류 (A 포인터 - 투 - 기능의 구조체 같은) VTABLE의 유형을 기술 할 것 (어쩌면 DW_AT_containing_type 이를 위해 용도 변경 될 수 있습니다.)
• 특성 개체 포인터의 내부를 더 자세히 설명합니다. DWARF가 주어진 함수의 vtable 슬롯을 계산하는 방법을 설명하고 있지만 "이 개체의 구성원이 vtable입니다"를 나타내는 방법이없는 것 같기 때문에 현재는 약간의 해킹을 통해 수행해야한다고 생각합니다. .

그런 다음 디버거는 다음을 수행하여 트레이 트 개체 포인터를 인쇄 할 수 있습니다. 값의 유형에 vtable이있는 경우 하위 항목에서 vtable을 가져오고 DWARF에서 vtable의 주소를 조회하여 vtable 유형을 찾은 다음 구체적인 유형을 사용하여 페이로드 포인터를 디코딩합니다.

나는이 일을하고있다. rustc가 작은 DWARF 확장 ( DW_AT_containing_type ) 아이디어를 내도록하는 LLVM 패치가 있습니다. vtable의 기본 사항 (메소드를 내 보내지 않고 주소 및 포함하는 유형)을 내보내는 rustc 패치와 모든 것을 읽고 print 작동하도록 만드는 대부분의 gdb 패치.

오늘 첫 성공 :

(gdb) p tu
$1 = traitobjtest::&T {pointer: 0x7fffffffe047 "\027\070\340\377\377\377\177\000", vtable: 0x5555555c34e8 <vtable> "\360\253UUUU\000"}
(gdb) p *tu
$2 = 23

신난다!

LLVM 패치는 여기에 있습니다 : http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20171016/495458.html

phabricator로 이동했습니다. https://reviews.llvm.org/D39503 을 따르는 것이 더 간단 할 수도 있습니다.

트레이 트 객체를 인쇄하기위한 gdb 패치는 여기에 있습니다 : https://sourceware.org/ml/gdb-patches/2017-11/msg00289.html

파트 2는 vtable의 필드를 설명하여 수행 할 수 있습니다. 나는 이것이 얼마나 어려운지보기 위해 rustc 비트를 보지 않았습니다. gdb의 info vtbl 비트는 어렵지 않으며 대부분 기존 명령을 조금 더 가상화합니다. 거기에 올바른 필드 이름이 있으면 특성 개체에 대한 메서드 호출을 구현하는 것도 간단해야하는 것 같습니다.

gdb 패치 버전 2는 여기에 있습니다 : https://sourceware.org/ml/gdb-patches/2017-11/msg00369.html

gdb 패치는 현재 있지만 구현해야 할 다른 vtable 작업이 남아 있으므로이 문제는 열어 두어야한다고 생각합니다.

@tromey "vtable 작업"에 gdb 변경이 필요합니까 아니면 rustc 변경 만 필요합니까?

@tromey "vtable 작업"에 gdb 변경이 필요합니까 아니면 rustc 변경 만 필요합니까?

이상적으로는 둘 다 필요하다고 생각합니다. 그러나 rustc 비트를 수행하는 것만으로도 좋은 시작이 될 것입니다 (어쨌든 이것이 먼저 와야합니다). 여기서 작업은 rustc가 DWARF의 vtable에 대한 전체 설명을 내보내도록하는 것입니다. 즉, 각 구성원의 유형과 이름입니다.