전체 글 (484) 썸네일형 리스트형 [Arm프로세서] Armv8 - SP_ELn과 X30 레지스터란? [Arm프로세서] Armv8 - SP_ELn과 X30 레지스터란? Armv8 아키텍처에서 정의된 레지스터 중 SP_ELn과 X30 레지스터는 AAPCS와 연관된 핵심 레지스터입니다. 전체 레지스터 목록 중에서 SP_ELn과 X30 레지스터를 먼저 소개하겠습니다. 전체 레지스터 목록 중 SP_ELn과 X30 레지스터 다음 그림을 보면서 Armv8 아키텍처에서 정의된 레지스터 중 AAPCS와 연관된 레지스터 목록을 알아봅시다. 그림 13.1 Armv8 아키텍처의 레지스터 목록 중 AAPCS와 연관된 레지스터 위 그림은 Armv8 아키텍처에서 정의된 레지스터 목록입니다. 그림에서 빗금으로 표기된 박스를 보겠습니다. SP_EL1은 EL1(익셉션 레벨1)에서 실행되는 SP 레지스터, SP_EL0는 EL0(익셉션 .. [Arm프로세서] Armv8 - AAPCS 관련 레지스터 Armv8 아키텍처의 AAPCS를 다루기에 앞서 Armv7에서 정의된 AAPCS의 주요 내용을 요약하면 다음과 같습니다. 서브루틴을 호출하면 프로세스의 스택 공간에 레지스터를 푸시한다. 'BL [주소]' 명령어를 실행해 서브루틴으로 분기하면 Arm 코어는 링크 레지스터인 R14에 복귀할 주소를 업데이트한다. 서브루틴을 호출할 때 전달되는 인자는 R0 ~ R3 레지스터에 저장된다. 함수의 리턴값은 R0 레지스터에 저장된다. 위에서 설명한 내용은 Armv8 아키텍처 관점에서 다음과 같이 바꿔서 설명할 수 있습니다. 서브루틴을 호출하면 프로세스의 스택 공간에 레지스터를 푸시한다. 'BL [주소]' 명령어를 실행해 서브루틴으로 분기하면 Arm 코어는 링크 레지스터인 X30에 복귀할 주소를 .. [리눅스 커널] 리눅스 커널에서의 인터럽트 처리 흐름 리눅스 커널에서의 인터럽트 처리 흐름 인터럽트가 발생했을 때 커널이 이를 처리하는 과정은 다음과 같이 3단계로 나눌 수 있습니다. 1 단계: 인터럽트 발생 인터럽트가 발생하면 프로세스 실행을 중지하고 인터럽트 벡터로 이동합니다. 인터럽트 벡터에서 인터럽트 처리를 마무리한 후 다시 프로세스를 실행하기 위해 실행 중인 프로세스 레지스터 세트를 스택에 저장합니다. 이후 커널 내부 인터럽트 함수를 호출합니다. 2단계: 인터럽트 핸들러 호출 커널 내부에서는 발생한 인터럽트에 대응하는 인터럽트 디스크립터를 읽어서 인터럽트 핸들러를 호출합니다. 3단계: 인터럽트 핸들러 실행 인터럽트 핸들러에서 하드웨어를 직접 제어하고 유저 공간에 이 변화를 알립니다. 이해를 돕기 위해 한 가지 예를 들어보겠습니다. 안드로.. [리눅스커널] ARM 프로세서 관점의 시스템 콜 처리 ARM 프로세서 관점의 시스템 콜 처리 리눅스 시스템에서 시스템 콜 관련 코드를 읽다 보면 어셈블리 코드를 만나게 됩니다. 보통 어셈블리 코드는 ARM 프로세서 입장에서 실행하는 동작입니다. 어셈블리 코드로 구현돼 있으니 시스템 콜이 아키텍처(ARM, x86) 동작과 연관이 있다고 볼 수 있습니다. 라즈베리 파이는 ARMv7 아키텍처에서 구동되므로 ARMv7(Aarch32, ARM 32비트) 프로세서 기준으로 시스템 콜의 세부 동작 방식을 알아보겠습니다. ARM 프로세서 모드 ARM 프로세서에서 시스템 콜이 어떻게 동작하는지 알려면 ARM 프로세스 모드에 대해 알아야 합니다. ARM 프로세서는 다음과 같이 6가지 모드를 지원하며, 각 모드별 레지스터 세트를 저장합니다. Supervisor FIQ .. [리눅스커널] 시스템 콜의 특징 시스템 콜의 특징 이번 절에서는 시스템 콜의 특징을 알아보겠습니다. 앞서 알아봤듯이 시스템 콜은 유저 모드에서 커널 모드로 진입하는 관문입니다. 소프트웨어 구조 관점에서 보면 시스템 콜은 유저 공간과 커널 공간 사이의 가상 계층으로 볼 수도 있습니다. 이 계층은 다음과 같은 특징이 있습니다. 1. 시스템 콜 계층으로 시스템 안정성과 보안을 지킬 수 있습니다. 유저 모드에서 애플리케이션이 커널 공간에 아무런 제약 없이 접근한다고 가정해 봅시다. 실수로 애플리케이션이 커널 코드 영역의 메모리를 오염시키면 시스템이 오동작할 가능성이 높습니다. 그래서 유저 모드에서 시스템 콜로만 커널 모드에 진입해서 제한된 메모리 공간에 접근하는 것입니다. 2. 유저 애플리케이션에서 추상화된 하드웨어 인터페이스를 제공합니다. .. [리눅스커널] 시스템 콜의 전체 흐름과 계층 이전 절에서 시스템 콜을 구성하는 주요 개념을 알아봤습니다. 이번에는 시야를 넓혀 전체 리눅스 시스템에서의 시스템 콜 실행 흐름을 살펴보겠습니다. 시스템 콜의 전체 흐름 파악하기 다음 그림은 이번 장에서 다룰 시스템 콜의 전체 흐름입니다. 그림 11.2 시스템 콜의 전체 흐름 먼저 위 그림에서 유저 공간이라고 표시된 부분을 눈으로 따라가 봅시다. open(), write(),read() 함수는 파일을 열거나 읽고 쓰는 파일 입출력 동작이고, fork()와 exit() 함수는 프로세스 생성 및 종료와 연관된 동작을 실행합니다. 이를 리눅스 저수준 함수라고 부릅니다. 다른 관점에서 GNU C 라이브러리로 진입하는 함수이며, API(Application Programming Interface)라고도 합니다. .. ftrace와 커널 로그로 인터럽트 컨텍스트 확인해보기 ftrace와 커널 로그로 인터럽트 컨텍스트 확인해보기 이번 절에서는 ftrace 로그를 분석하면서 커널이 인터럽트를 어떻게 처리하는지 알아봅시다. 리눅스 커널에서 커널 동작을 가장 정밀하게 담고 있는 로그는 뭘까요? 아마 많은 리눅스 전문가들은 ftrace라고 대답할 겁니다. ftrace는 리눅스 커널에서 제공하는 가장 강력한 디버그 로그입니다. 리눅스 커널의 공식 트레이서이기도 합니다. 여러분도 ftrace 로그를 자주 활용해서 리눅스 커널을 익히기를 바랍니다. ftrace로 인터럽트를 처리하는 인터럽트 핸들러 함수에 필터를 걸고 콜 스택 로그를 받아 보겠습니다. 인터럽트 동작을 확인하기 위한 ftrace 설정 ftrace로 인터럽트의 동작 방식을 분석하기 전에 ftrace를 설정하는 방법을 소개합니.. [리눅스커널] 인터럽트를 잘 알아야 하는 이유 커널이 인터럽트를 처리하는 과정과 자료구조를 왜 잘 알아야 할까요? 인터럽트를 처리하는 방식이 시스템 전반에 큰 영향을 끼치기 때문입니다. 또한 리눅스 커널 시스템 전반을 잘 이해하기 위해서도 커널이 인터럽트를 어떻게 처리하는지 잘 알고 있어야 합니다. 또 다른 이유는 다음과 같습니다. 대부분의 리눅스 드라이버는 인터럽트를 통해 하드웨어 디바이스와 통신합니다. 그래서 디바이스 드라이버 코드를 처음 분석할 때 인터럽트를 처리하는 함수나 코드를 먼저 확인합니다. 인터럽트의 동작 방식을 잘 알고 있으면 디바이스 드라이버 코드를 빨리 이해할 수 있습니다. 인터럽트가 발생하면 프로세스는 이미 정해진 동작을 수행합니다. 인터럽트 처리 과정을 숙지하면 프로세스가 스택 메모리 공간에서 어떻게 실행되는지 알게 됩.. 이전 1 ··· 3 4 5 6 7 8 9 ··· 61 다음