LINUX · PERF · BUILD IDENTITY

인라인 코드의 probe 위치는 빌드에 묶입니다

함수 이름이 없다고 해서 실행할 코드가 없는 것은 아닙니다.

소스의 함수와 실제 명령 주소를 구분합니다

최적화로 인라인된 함수는 독립된 호출 지점이나 심볼 없이 여러 호출자 안에 놓일 수 있습니다. Brendan Gregg의 2014년 사례는 DWARF와 소스 행 정보를 이용해 이 코드의 관찰 지점을 찾습니다. 그 사례의 +88·+155 같은 상대 행 번호는 다른 커널의 좌표가 아닙니다.

실행 중인 커널 또는 모듈, 해당 빌드의 디버그 정보와 소스를 함께 식별합니다. 최적화·설정·컴파일러가 달라지면 같은 소스 행의 명령 배치와 변수 위치도 달라질 수 있습니다. 이름만 같은 vmlinux로 위치가 맞는다고 판단하지 않습니다.

후보 조회와 실제 등록을 분리합니다

perf-probe 매뉴얼은 --line으로 probe 가능한 소스 행을, --vars로 해당 지점에서 얻을 수 있는 변수를 조회하도록 설명합니다. 최적화된 변수는 해당 위치에서 복원되지 않을 수 있습니다. --no-inlines는 비인라인 함수만 찾는 --add 옵션이므로, 인라인 지점을 찾으려는 목적과 반대일 수 있습니다.

--definition은 변환된 이벤트 정의를 출력하고 실제 tracing 이벤트 파일에는 쓰지 않습니다. --dry-run도 --add·--del의 실제 등록·제거를 생략합니다. 매뉴얼의 오프라인 vmlinux 사용 조건은 --definition과 함께 쓰는 경우입니다. 실제 등록은 별도의 시스템 변경이며 권한·지원 여부를 확인해야 합니다.

한 지점의 이벤트를 함수 전체 호출로 확대하지 않습니다

관찰 결과에는 선택한 명령 지점, 생성된 이벤트 수, 변수 수집 성공 여부와 빠진 표본을 함께 남깁니다. 인라인 함수의 여러 구현 위치 중 일부만 선택했다면 그 계수는 선택한 위치의 계수입니다. 소스의 모든 호출을 셌다는 뜻이 아닙니다.

오래된 예시의 출력은 설명용 이력으로 읽고 현재 장비의 실행 결과처럼 표시하지 않습니다. 이 글은 원문과 도구 문서를 대조한 설명이며, 커널에 probe를 설치하거나 성능 수치를 측정한 결과는 아닙니다.

관찰 위치를 확정하는 세 단계
  1. 빌드 식별

    커널·모듈과 디버그 정보 연결

  2. 위치 확인

    소스 행·명령·가용 변수 대조

  3. 범위 기록

    관찰한 위치와 빠진 범위 구분

사용자 공간에서는 USDT 마커와 동적 uprobe를 구분합니다

앞의 커널 인라인 코드 사례와 달리 이 절은 실행 파일·공유 라이브러리의 사용자 공간 관측을 다룹니다. 동적 uprobe는 관측자가 대상 코드 위치를 선택합니다. USDT는 프로그램 작성자가 의미 있는 지점에 마커와 provider/name을 마련합니다. 두 개는 배타적인 커널 기능이 아닙니다. Linux 도구는 USDT 마커를 찾은 뒤 uprobe를 이용해 수집할 수 있습니다.

동적 uprobe는 관측자가 코드 위치를 고르고, USDT는 프로그램 작성자의 마커 이름과 메타데이터를 통해 위치를 찾는다. 두 경로 모두 대상 빌드와 수집 도구의 지원 확인이 필요하다.
의미를 고르는 방법과 실제 수집 수단을 구분한 자체 도식입니다. 실행 측정값은 아닙니다.
선택 방식출발점별도로 확인할 조건
동적 uprobe실행 파일·라이브러리의 함수 또는 코드 위치대상 빌드, 정확한 파일 오프셋, 가용 인자와 ABI
USDT 마커프로그램이 제공하는 provider/name과 마커 메타데이터해당 빌드의 마커 존재, 의미·인자 계약, 수집 도구의 지원

Linux v6.18.37 uprobe-tracer 인터페이스의 PATH:OFFSET은 실행 파일이나 라이브러리 안의 위치를 지정합니다. 런타임 가상주소를 그대로 넣는 규칙이 아니며, 인터페이스는 정확한 객체 오프셋 계산을 호출자에게 요구합니다. probe 정의 직후 이벤트는 기본적으로 비활성 상태이므로 정의·활성화·기록 성공을 같은 단계로 세지 않습니다.

USDT 이름은 내부 C/C++ 함수명보다 업무상 의미를 드러내는 인터페이스가 될 수 있지만 모든 릴리스에서 자동으로 고정되는 계약은 아닙니다. 실제 바이너리에 마커가 들어 있는지, 인자의 형식과 의미가 그 빌드에서 무엇인지 확인합니다. 마커가 없다고 관련 코드가 실행되지 않는 것은 아니며, 마커에 없는 정보가 자동으로 수집되는 것도 아닙니다.

perf의 발견·변환과 실제 추적을 나눕니다

같은 v6.18.37 perf-probe 문서는 SDT provider/event 이름 사용 전에 대상 바이너리를 perf-buildid-cache로 조사해 캐시해야 한다고 설명합니다. probe-event.c의 find_probe_trace_events_from_cache()는 SDT 이름을 대상 또는 전체 유효 캐시에서 찾고, convert_to_probe_trace_events()는 SDT 캐시에서 찾지 못하면 일반 함수 탐색으로 대체하지 않고 오류를 반환합니다. 이름이 같아도 다른 바이너리의 캐시를 같은 관측 대상으로 간주하지 않습니다.

일부 마커는 활성 여부를 알리는 semaphore를 사용합니다. 같은 소스의 warn_uprobe_event_compat()는 semaphore가 있는데 커널 지원이 없으면 경고합니다. 따라서 정적 마커라고 해서 활성화·인자 해석·권한 조건이 사라지지는 않습니다. 특정 perf 버전의 캐시 경로를 모든 eBPF 프런트엔드의 공통 구현으로 일반화하지 않습니다.

Brendan Gregg의 2015년 원문은 이 구분을 설명하는 역사적 사례입니다. 작성자는 수동 ftrace 우회 실험을 권장하지 않았고 2017년 갱신에서 perf와 BCC/eBPF의 USDT 지원을 알립니다. 여기서는 당시 고정 주소, 프로세스 메모리 쓰기, 인자 추출 명령을 현행 절차로 옮기지 않습니다. probe 설치·수집·성능 측정은 실행하지 않았습니다.

English: marker semantics and collection mechanics

USDT supplies an application-defined marker interface; uprobes can be the mechanism used to collect it. A marker name does not remove binary, argument, activation or tool-version requirements. The v6.18.37 perf cache path is one implementation, not a universal eBPF workflow. No probe installation or process-memory modification was performed.

출처와 연결

/proc·strace·perf의 관찰 범위