- VisualStudio2022插件的安装及使用-编程手把手系列文章
- pprof-在现网场景怎么用
- C#实现的下拉多选框,下拉多选树,多级节点
- 【学习笔记】基础数据结构:猫树
任何玩过Arm64架构的朋友都知道,我们的ARM64架构有异常:Exception Levels, ELs,它是其异常处理机制的核心组成部分,允许系统在不同的特权级别下执行代码。ARM64定义了四个异常级别,每个级别具有不同的特权、功能和访问权限。以下是对每个异常级别的详细介绍:
当系统发生异常时,ARM64会根据当前的异常级别和异常类型自动转移到相应的更高异常级别。这个切换过程通常包括:
我们的异常分为两个大类:依照我们执行时异常的发生方式分为同步异常和异步异常.
笔者花费一些时间阅读了Entry.S文件,得到了这个结论.
外面首先锁定到这里,找到这个文件:定位到这个代码段:
arch/arm64/kernel/entry.S 。
SYM_CODE_START(vectors)
kernel_ventry 1, t, 64, sync // Synchronous EL1t
kernel_ventry 1, t, 64, irq // IRQ EL1t
kernel_ventry 1, t, 64, fiq // FIQ EL1t
kernel_ventry 1, t, 64, error // Error EL1t
kernel_ventry 1, h, 64, sync // Synchronous EL1h
kernel_ventry 1, h, 64, irq // IRQ EL1h
kernel_ventry 1, h, 64, fiq // FIQ EL1h
kernel_ventry 1, h, 64, error // Error EL1h
kernel_ventry 0, t, 64, sync // Synchronous 64-bit EL0
kernel_ventry 0, t, 64, irq // IRQ 64-bit EL0
kernel_ventry 0, t, 64, fiq // FIQ 64-bit EL0
kernel_ventry 0, t, 64, error // Error 64-bit EL0
kernel_ventry 0, t, 32, sync // Synchronous 32-bit EL0
kernel_ventry 0, t, 32, irq // IRQ 32-bit EL0
kernel_ventry 0, t, 32, fiq // FIQ 32-bit EL0
kernel_ventry 0, t, 32, error // Error 32-bit EL0
SYM_CODE_END(vectors)
ARM64架构中不同异常向量的处理入口点(vector entry points)。每个kernel_ventry行代表一个特定异常类型在不同异常级别和模式下的处理方式。下面列个表说明:
kernel_ventry
: 这是一个宏或函数,表示定义一个异常处理程序的入口点。1
或0
)通常表示异常级别(1表示EL1,0表示EL0)。t
或h
)表示异常类型(t
表示异常,h
表示虚拟化)。64
或32
)表示处理器的位数(64位或32位)。sync
、irq
等)。也就是说这个汇编文件实际上就是描述了不同的Exception Level下的不同的异常类型的处理机制表.
很好,但是当你browse大部分博客准备查看我们的异常exception vector handler在哪里的时候,你会惊喜的发现自己找不到handler了!在哪里呢?在这里! 。
当然,这是为了简化在ARM64内核中定义异常处理程序的流程,通过参数化异常级别、处理类型和寄存器大小,方便地创建多个处理程序。这种结构化的方式有助于保持代码的整洁和可维护性。(但是苦了我这种喜欢读recent源码的人) 。
.macro entry_handler el:req, ht:req, regsize:req, label:req
SYM_CODE_START_LOCAL(el\el\ht\()_\regsize\()_\label)
kernel_entry \el, \regsize
mov x0, sp
bl el\el\ht\()_\regsize\()_\label\()_handler # 跳转到这个异常的handler
.if \el == 0
b ret_to_user
.else
b ret_to_kernel
.endif
SYM_CODE_END(el\el\ht\()_\regsize\()_\label)
.endm
/*
* Early exception handlers
*/
entry_handler 1, t, 64, sync
entry_handler 1, t, 64, irq
entry_handler 1, t, 64, fiq
entry_handler 1, t, 64, error
entry_handler 1, h, 64, sync
entry_handler 1, h, 64, irq
entry_handler 1, h, 64, fiq
entry_handler 1, h, 64, error
entry_handler 0, t, 64, sync
entry_handler 0, t, 64, irq
entry_handler 0, t, 64, fiq
entry_handler 0, t, 64, error
entry_handler 0, t, 32, sync
entry_handler 0, t, 32, irq
entry_handler 0, t, 32, fiq
entry_handler 0, t, 32, error
不着急一点点看:
SYM_CODE_START_LOCAL(el\el\ht\()_\regsize\()_\label)
el
:表示异常级别(例如EL0、EL1等)。ht
:表示处理类型(可能指同步或异步)。regsize
:表示寄存器大小(如32位或64位)。label
:定义处理程序的标签名称。kernel_entry \el, \regsize
el
和regsize
初始化异常处理的上下文。mov x0, sp
x0
,这通常用于传递参数或保存上下文。bl el\el\ht\()_\regsize\()_\label\()_handler
bl
指令用于调用指定的异常处理程序。在这里,它根据传入的参数构造处理程序名称,调用实际的异常处理函数。if \el == 0
b ret_to_user
.else
b ret_to_kernel
.endif
el
是0,表示用户模式,则跳转到ret_to_user
,该标签通常处理返回用户态的逻辑。el
不是0,表示内核模式,则跳转到ret_to_kernel
,用于返回内核态的逻辑。SYM_CODE_END(el\el\ht\()_\regsize\()_\label)
.endm
很好!我们大致明白了:实际上这个handler就是处理完毕后判断需要调回哪个层级(内核态还是用户态),最后,我们需要揭露以下kernel_entry的神秘面纱
回到这个文件的开头:
.macro kernel_ventry, el:req, ht:req, regsize:req, label:req
.align 7
.Lventry_start\@:
.if \el == 0
/*
* This must be the first instruction of the EL0 vector entries. It is
* skipped by the trampoline vectors, to trigger the cleanup.
*/
b .Lskip_tramp_vectors_cleanup\@
.if \regsize == 64
mrs x30, tpidrro_el0
msr tpidrro_el0, xzr
.else
mov x30, xzr
.endif
.Lskip_tramp_vectors_cleanup\@:
.endif
sub sp, sp, #PT_REGS_SIZE
#ifdef CONFIG_VMAP_STACK
/*
* Test whether the SP has overflowed, without corrupting a GPR.
* Task and IRQ stacks are aligned so that SP & (1 << THREAD_SHIFT)
* should always be zero.
*/
add sp, sp, x0 // sp' = sp + x0
sub x0, sp, x0 // x0' = sp' - x0 = (sp + x0) - x0 = sp
tbnz x0, #THREAD_SHIFT, 0f
sub x0, sp, x0 // x0'' = sp' - x0' = (sp + x0) - sp = x0
sub sp, sp, x0 // sp'' = sp' - x0 = (sp + x0) - x0 = sp
b el\el\ht\()_\regsize\()_\label
0:
/*
* Either we've just detected an overflow, or we've taken an exception
* while on the overflow stack. Either way, we won't return to
* userspace, and can clobber EL0 registers to free up GPRs.
*/
/* Stash the original SP (minus PT_REGS_SIZE) in tpidr_el0. */
msr tpidr_el0, x0
/* Recover the original x0 value and stash it in tpidrro_el0 */
sub x0, sp, x0
msr tpidrro_el0, x0
/* Switch to the overflow stack */
adr_this_cpu sp, overflow_stack + OVERFLOW_STACK_SIZE, x0
/*
* Check whether we were already on the overflow stack. This may happen
* after panic() re-enables interrupts.
*/
mrs x0, tpidr_el0 // sp of interrupted context
sub x0, sp, x0 // delta with top of overflow stack
tst x0, #~(OVERFLOW_STACK_SIZE - 1) // within range?
b.ne __bad_stack // no? -> bad stack pointer
/* We were already on the overflow stack. Restore sp/x0 and carry on. */
sub sp, sp, x0
mrs x0, tpidrro_el0
#endif
b el\el\ht\()_\regsize\()_\label # 还是一样,最后跳转道实际的处理程序上去
.org .Lventry_start\@ + 128 // Did we overflow the ventry slot?
.endm
下面慢慢说:
.macro kernel_ventry, el:req, ht:req, regsize:req, label:req
.align 7
.Lventry_start\@:
.if \el == 0
b .Lskip_tramp_vectors_cleanup\@
.if \regsize == 64
mrs x30, tpidrro_el0
msr tpidrro_el0, xzr
.else
mov x30, xzr
.endif
.Lskip_tramp_vectors_cleanup\@:
.endif
sub sp, sp, #PT_REGS_SIZE
kernel_ventry
宏定义了内核在不同异常级别和寄存器大小下的入口逻辑。b .Lskip_tramp_vectors_cleanup\@
用于跳过清理操作。x30
寄存器。#ifdef CONFIG_VMAP_STACK
add sp, sp, x0
sub x0, sp, x0
tbnz x0, #THREAD_SHIFT, 0f
sub x0, sp, x0
sub sp, sp, x0
b el\el\ht\()_\regsize\()_\label
0:
msr tpidr_el0, x0
sub x0, sp, x0
msr tpidrro_el0, x0
adr_this_cpu sp, overflow_stack + OVERFLOW_STACK_SIZE, x0
mrs x0, tpidr_el0
sub x0, sp, x0
tst x0, #~(OVERFLOW_STACK_SIZE - 1)
b.ne __bad_stack
sub sp, sp, x0
mrs x0, tpidrro_el0
#endif
此段代码检测堆栈溢出并执行相应的处理.
sp
来检查堆栈溢出情况。b el\el\ht\()_\regsize\()_\label
.org .Lventry_start\@ + 128 // Did we overflow the ventry slot?
.endm
现在我们总结以下:
我们的现代内核采用汇编宏的办法定义了一个及其灵活的内核异常句柄表。他排列开来,使用一个handler模板生成对应的注册机制。进入中断向量,他首先要检查堆栈情况(看看是堆栈溢出还是其他错误),然后跳转道实际的处理函数(这个要在外面找,但是遗憾的是目前没有找到 😦 ),随后要做清理退出,根据进入处理句柄的时候是内核态还是用户态来决定是返回恢复哪里的堆栈信息.
就是这样! 。
最后此篇关于Linux内核源码阅读:AArch64的异常处理机制详谈(内核版本6.11)的文章就讲到这里了,如果你想了解更多关于Linux内核源码阅读:AArch64的异常处理机制详谈(内核版本6.11)的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。
问题很简单:我正在寻找一种优雅的使用方式 CompletableFuture#exceptionally与 CompletableFuture#supplyAsync 一起.这是行不通的: priva
对于 Web 服务,我们通常使用 maven-jaxb2-plugin 生成 java bean,并在 Spring 中使用 JAXB2 编码。我想知道如何处理 WSDL/XSD 中声明的(SOAP-
这个问题已经有答案了: Array index out of bound behavior (10 个回答) 已关闭 8 年前。 我对下面的 C 代码感到好奇 int main(){
当在类的开头使用上下文和资源初始化 MediaPlayer 对象时,它会抛出 NullPointer 异常,但是当在类的开头声明它时(因此它是 null),然后以相同的方式初始化它在onCreate方
嘿 我尝试将 java 程序连接到 REST API。 使用相同的代码部分,我在 Java 6 中遇到了 Java 异常,并且在 Java 8 中运行良好。 环境相同: 信任 机器 unix 用户 代
我正在尝试使用 Flume 和 Hive 进行 Twitter 分析。为了从 twitter 获取推文,我在 flume.conf 文件中设置了所有必需的参数(consumerKey、consumer
我在 JavaFX 异常方面遇到一些问题。我的项目在我的 Eclipse 中运行,但现在我的 friend 也尝试访问该项目。我们已共享并直接保存到保管箱文件夹中。但他根本无法让它发挥作用。他在控制台
假设我使用 blur() 事件验证了电子邮件 ID,我正在这样做: $('#email').blur(function(){ //make ajax call , check if dupli
我这样做是为了从 C 代码调用非托管函数。 pCallback 是一个函数指针,因此在托管端是一个委托(delegate)。 [DllImport("MyDLL.dll")] public stati
为什么这段代码是正确的: try { } catch(ArrayOutOfBoundsException e) {} 这是错误的: try { } catch(IOException e) {} 这段
我遇到了以下问题:有导出函数的DLL。 代码示例如下:[动态链接库] __declspec(dllexport) int openDevice(int,void**) [应用] 开发者.h: __de
从其他线程,我知道我们不应该在析构函数中抛出异常!但是对于下面的例子,它确实有效。这是否意味着我们只能在一个实例的析构函数中抛出异常?我们应该如何理解这个代码示例! #include using n
为什么需要异常 引出 public static void main(String[
1. Java的异常机制 Throwable类是Java异常类型的顶层父类,一个对象只有是 Throwable 类的(直接或者间接)实例,他才是一个异常对象,才能被异常处理机制识别。JDK中内
我是 Python 的新手,我对某种异常方法的实现有疑问。这是代码(缩写): class OurException(Exception): """User defined Exception"
我已经创建了以下模式来表示用户和一组线程之间的关联,这些线程按他们的最后一条消息排序(用户已经阅读了哪些线程,哪些没有): CREATE TABLE table(user_id bigint, mes
我正在使用 Python 编写一个简单的自动化脚本,它可能会在多个位置引发异常。在他们每个人中,我都想记录一条特定的消息并退出程序。为此,我在捕获异常并处理它(执行特定的日志记录操作等)后引发 Sys
谁能解释一下为什么这会导致错误: let xs = [| "Mary"; "Mungo"; "Midge" |] Array.iter printfn xs 虽然不是这样: Array.iter pr
在我使用 Play! 的网站上,我有一个管理部分。所有 Admin Controller 都有一个 @With 和一个 @Check 注释。 断开连接后,一切正常。连接后,每次加载页面(任何页面,无论
我尝试连接到 azure 表存储并添加一个对象。它在本地主机上工作得很好,但是在我使用的服务器上我得到以下异常及其内部异常: Exception of type 'Microsoft.Wind
我是一名优秀的程序员,十分优秀!