사용 이유
0. 버퍼에 씀 > 빠름 // /kernel/debug/tracing cat buffer_size_kb
1. 코드 수정 X (이미 만들어짐)
2. printk, dump_stack에 비해 자원소모 적음
3. 인터럽트, 스케쥴링, 타이머 등 상세히 볼 수있음
: tracing/events
추적가능한 함수들
/sys/kernel/debug/tracing cat available_filter_function | grep
./set_ftrace.sh
cat /proc/interrupts
./get_ftrace.sh
ftraceLogs
task > idle : 쉬는중
PID > 다른 탭에서 ps -e 하면 나옴 process ID
CPU : 몇번째 코어 쓰는지 (#p : 4)
TIMESTAMP : (초).(us) ex) 4540초 002552us
FUNCTION : 그 TIME 에 동작한 함수
need-resched : 스케쥴링 필요성 'N' : 모든게 다 필요 (TIF,PREEMPT), 'n' : TIF 만 필요, 'p' : PREEMPT만 필요
// '.' 은 그 외 경우 , preemt(preemtion) : 선점형 <> 비선점형 : 순차적 FIFO
5482 cat-1082 rpi_get_interrupt_info+0x4/0x50 <-show_interrupts+0x2b0/0x400
:
(0x400크기) show함수+0x2b0 위치 에서 (0x50크가) rpi_get함수+0x4 를 cat 함
<stack trace>
// 밑에서부터 쌓이며 위에서부터 빠져나감
5483 rpi_get_interrupt_info+0x8/0x50
5484 show_interrupts+0x2b0/0x400
"
"
5494 el0_svc+0x30/0x9c
5495 el0t_64_sync_handler+0xf4/0x120
5496 el0t_64_sync + 0x18c /0x190
1. el0t_64_sync(0x190크기) + 0x18c 지점에서 > el0t_64_sync_handler(0x120크기) 호출 !
2. el0t_64_sync_handler + 0xf4 지점에서 el0_svc 함수 호출!
"
"
10. show_interrupts +0x2b0 지점에서 rpi_get_interrupt_info 호출!
11. rpi_get_interrupt_info + 0x8 에서 종료 !
<sched_switch>
13 set_ftrace.sh-774 [003] d..2. 286.088402: sched_switch: prev_comm=set_ftrace.sh prev_pid=774 prev_prio=120 prev_state=R+ ==> next_comm=kworker/u12:1 next_pid=139 next_prio=120
set_ftrace.sh-774에서 컨택스트 스위치 발생
: prev_comm=set_ftrace.sh // 기존 프로세스
prev_pid=774 // 기존 pid
prev_prio=120 // 기존 우선순위
prev_state=R+ // 기존 상태
>>>>
next_comm=kworker/u12:1 // 다음 프로세스 :kworker
next_pid=139 // 다음 pid
next_prio=120 // 다음 우선순위
함수 코드 <> ftrace
handler_entry(irq,action) irq_handler_entry
hanler(irq,action->dev_id) sched_swtich, <stack trace> 등등
handler_exit(irq,action,res) irq_handler_exit
/*
apt-get install exuberant-ctags
> ctags 파일명 -> 태그 생성
> ctrl + ] == stm32 ctrl + 좌클릭 과 비슷함
*/
warker.c > insert 함수 -> printk ( )
__func : 현재 함수명
__Line : 현재 줄 수
__bulltin_return_address (0) : 본 함수를 호출한 caller 함수
// GCC컴파일러 내장 함수
// linux/arch/arm64 : currnet 등 아키텍쳐 마다의 내장함수
> build, install, reboot -> dmesg
dump_stack
// fork : process중 process 를 불러오는
kernel-clone 함수
{
copy_process(); // fork
dump_stack();
}
>
dump_stack ~~
dump_stack ~~
dump_stack ~~
dump_stack ~~
kernel-clone
다른함수~~
다른함수~
>>
1.다른함수->다른함수-> kernel-clone 호출
2. kernel-clone -> dump_stack 호출 ( 자식 process)
>>>
해당 프로세스 생성후! 메모리 상태확인
// 그냥 하면 전체적인 흐름이 나옴
// 그래서 복제 후 그 process의 독립적인 내용 확인