저번 글에서는 qemu와 gdb를 통해 발생한 원인을 추적하는 방법에 대해 배웠습니다. 하지만 정확히 어느 부분이 문제인지 확인하는 것은 수고스러운 일이였습니다. 따라서 손쉬운 디버깅을 위해 WAIOS만의 dump_stack 함수를 구현해보도록 하겠습니다. 우선 구현 결과물은 아래와 같습니다. 위 정보를 통해 b 함수에서 dump_stack 함수가 호출된 것을 확인할 수 있습니다. 실제 문제가 발생한 상황이라면 b 함수를 조사함으로써 조금 더 편리한 디버깅이 될 것입니다. 이제 본격적으로 dump_stack 함수 구현을 해보도록 하겠습니다. 구현은 핵심 컨셉은 Linux의 kallsyms에서 가져왔습니다. 따라서 kallsyms에 대해 알고 있다면 글을 읽는데에 많은 도움이 될 것입니다. kallsysm는 다른 글을 통해 소개한 적이 있으므로 관심이 있으신 분은 아래의 링크를 참고하시면 되겠습니다. Stack trace와 kallsyms 구현 살펴

OS 개발 시 가장 힘든 부분은 역시 디버깅을 하는 것인데요. 이를 위해 앞에 글에서는 gdb+qemu와 같은 방법을 살펴봤습니다. 하지만 이 방법은 원인 분석하기엔 유용하지만, 문제가 발생한 위치를 쉽게 찾지는 못합니다. Linux에서는 문제가 발생할 경우 위와 같이 Oops나 panic을 통해 여러 정보들을 출력합니다. 위의 panic 로그는 어떤 위치에서 panic이 발생했는지와 각종 레지스터들의 상태와 call trace 같은 정보들은 제공합니다. 이런 정보들은 이용하면 맨 땅에서 디버깅할 때보다 수월하게 디버깅을 할 수 있습니다. 그렇다면 위와 같은 call trace를 출력하는 것은 어떻게 구현할까요? 이것을 구현하기 위해서는 우선 stack frame 개념에 대해 알아야 합니다. 이 주제는 다룬 글들이 많기에 간단하게 설명하도록 하겠습니다. Stack Frame ARM 64의 스택 프레임은 아래의 그림과 같습니다. frame poin

위 그림에 노란색 화살표가 대응하는 곳을 잘 보면 각 핀 네임이 (Vivado EDA 툴 GUI 메뉴에서 포트의 핀을 내가 원하는 모듈 인,아웃 포트에 대응하면 XDC 파일로 저장합니다.) 기판에 프린팅 되어 직접 나와있습니다. 다른 평가 기판의 경우를 살펴보면, Xilinx VC707 Evaluation Board의 경우는 기판에 핀 네임이 프린트 되어있지는 않고, 해당 항목이 매뉴얼에 나와있습니다. https://www.xilinx.com/support/documentation/boards_and_kits/vc707/ug885_VC707_Eval_Bd.pdf 자 이제, 그럼 Arty7-35 기준의 XDC 파일 예제를 보도록 할께요. 32 bit RISC-V 저전력 CPU 프로젝트인 ibex를 기준으로 살펴보면 (zero-riscy, pulpissimo-v6.0.0 릴리즈), 파일 주석에는 Arty A7-100 을 지원한다고 나와있는데, 사실 파

물론, 상용 EDA 툴인 Intel(Quartus)나 Xilinx(Vivado)를 사용하면 GUI 기반으로 편하게 사용하면 되지만, 우리는 오픈소스를 지향하고 또 RTL 학습하는데 필요한 기능이 중심 되기 때문에 수 십 GB 용량의 설치를 안하고도 충분하다고 생각을 했습니다. 물론 보드가 있으면 위의 2가지 툴로 해봐도 무방합니다. 또 설치하지 않고 웹 기반의 EDA 베릴로그 소스를 인터프리팅하고 회로의 타이밍 시뮬레이션 및 테스트벤치를 실행할 수 있습니다. 우선 예시의 빌드 환경 기준으로 설치가 잘 되었는지 확인해볼까요? 간단한 예제를 한번 작성하고 돌려볼께요. 자세한 설명은 예제를 작성하고 조금 이따가 같이 이야기 하자구요! a, b 두개의 입력을 받습니다. 2개의 입력의 크기는width 만큼의 bit 이구요. 1 bit c_in 입력을 받습니다. 실질적으로 이 모듈이 하는 일은 두 a, b 와 c_in 을 합친 다음 1bit 의 output

nolibc.h 하나의 헤더 파일로 구성되어 있으며, v5.1-rc1 이후 tools/include/nolibc/nolibc.h 에 위치해 있습니다. 최소한의 syscall 및 main()을 호출하는 데 필요한 최소한의 시작 코드로 구성됩니다. 우선 파일을 열 때 쓰는 open() 시스템 콜을 nolibc 에서는 어떻게 구현되어 있는지 살펴보겠습니다. 커널 관점에서는 open() 시스템 콜에 대응은 어떻게 구현되어 있는지 살펴보겠습니다. 해당 인터페이스로 노출이 되어있고, 커널 쪽 open()의 구현을 볼 수 있습니다. 아래에서 보이는 대로 vfs_open()으로 들어가게 됩니다. 쭉 들어가면 open 할 때에 타입 플래그에 대한 분기에 따라 dentry, inode을 활용하여 파일 시스템마다 VFS 에 등록한 컬백을 활용함을 볼 수 있습니다. 다시 nolibc.h 로 돌아와서 아키텍쳐 별로 어떻게 구현되어 있는지 arm64 와 risc-v 두 가