在深入分析“centos 7 kernel 3.12 kgdb分析64位系统页地址分析和问题”这个标题和描述中所涉及的知识点之前，我们首先需要明确几个基础概念。
CentOS（Community ENTerprise Operating System）是一个基于Red Hat Enterprise Linux（RHEL）构建的社区企业操作系统版本，它的内核版本保持与RHEL同步。在这个背景之下，提及的kernel版本为3.12，说明是在Linux 3.12版本内核的环境下探讨问题。
kgdb即Kernel GNU Debugger，是一个内核级的调试器，允许用户在内核级别进行调试。kgdb用于开发者在开发Linux内核的过程中进行调试，也可以用于生产环境中调试内核相关问题。
然后，我们谈到64位系统。64位系统是指CPU和操作系统能够处理64位数据宽度，这对于系统的内存寻址能力有着巨大的提升，使得系统能够支持更大的物理和虚拟内存空间。
在64位系统中，页地址分析是一个复杂的过程，涉及到页表和页表项。页表是操作系统用来将虚拟地址映射到物理地址的表格，它记录了每个虚拟页面对应物理内存页的信息。页表项（Page Table Entry，PTE）是页表中的一个条目，它决定了一个虚拟页如何映射到物理内存。
接下来，我们逐步分析文档中提到的具体问题。
1. MadeByDearDeng可以call，而没有int3
这里的描述可能指的是在使用kgdb调试时，某些函数（如MadeByDearDeng）是可以调用的，但是并没有执行断点（int3）中断。通常情况下，int3是用于设置软件断点，它的作用是在指令流中插入一条特殊操作码（0x03），当CPU执行到这个操作码时，会触发异常并跳转到调试器的处理函数中。如果调用函数时没有触发int3，可能说明调用的函数并不在预期的断点位置，或者是调试器并没有设置断点。
2. 以0xffffffffa029b22b地址计算，得到的pt
Bit1为0，说明该页框可读不可写
这段描述指出，在对虚拟地址0xffffffffa029b22b进行分析时，通过某种计算方式得到了页表项（pt），且页表项中的第1位是0。在x86-64架构中，页表项中通常包含许多用于控制内存访问权限的标志位，其中第1位（通常称为Read/Write位）控制着对应的内存页是否可写。当这个位为0时，表明该内存页是只读的。
然而，问题是为什么在这个只读的页上，gdb（GNU Debugger）仍然能够进行调试。这可能指向几个方向：
- 第一，可能GDB使用了其他的机制来进行调试，而不是简单地通过在代码中插入断点（int3）。
- 第二，可能在进行调试时，操作系统和调试器采取了一些特殊措施，允许对只读页进行写操作，例如使用内核写保护机制中的写时复制（Copy-On-Write，COW）技术。COW机制允许在不修改原始页的情况下对页进行写操作，例如在fork创建子进程时，父子进程共享相同的物理页，但是任何试图修改该页的行为都会触发一个页面错误，从而复制一个新的页并进行修改。
- 第三，可能是文档中描述的情况有误或者不完整，实际调试过程中可能涉及到其他复杂的机制。
在分析和解决这类问题时，通常需要对内核的内存管理单元（MMU）的页表机制有较深入的理解，同时也需要考虑到在64位Linux内核中，页表结构可能会采用多级页表的形式来适应更大的地址空间。例如，二级分页机制使用中间级别的页表项，从而避免了在单级页表机制下对大容量内存的管理难度和内存开销。
在实际的内核调试中，遇到的这类问题往往需要结合具体的内核版本，硬件架构和调试环境来具体分析。调试器、操作系统、硬件之间的交互非常复杂，而内核开发者必须充分理解这些交互才能有效处理类似问题。由于篇幅限制，这里仅能提供一个关于64位系统页地址分析和问题的浅显概述，而实际的分析和解决问题则需要深入研究相关文档、内核源码以及调试工具的具体使用。
