有没有办法找出 libc 创建/访问了哪些匿名虚拟内存区域？
我有一个程序，mprotect它的地址空间上有 VMA。但是当它mprotect是一个将被 libc 访问的区域时，就会发生 SIGSEGV。不幸的是，我安装的信号处理程序只处理发生在我的代码上的错误，而不是 libc 的。
详细地说，我得到的错误是因为printf使用了可变参数。它尝试访问结构reg_save_area内的位置va_list。该位置属于我之前mprotect编辑的匿名 VMA。
那么，在我之前是否知道这些区域是哪些mprotect？或者至少有一种方法可以知道stdarg.h选择放置在哪里reg_save_area？
最干净的方法是处理 libc 中出现的 SIGSEGV。但我怀疑是否有这样的方法。
注意： libc 的 data/bss 段很容易识别，因为它不是匿名的。如果我mprotect也是那个 VMA，它也会导致一个未处理的 SIGSEGV，这就是我选择不这样做的原因。
对您的问题最简单的答案是：除了您自己明确映射的那些之外，所有这些都是。
不要做mprotect你自己没有做的记忆范围mmap。库，甚至可能内核会一直在你背后做事。他们将进行自己的分配和映射。您不能更改它们，因为它们不属于您的管理。
顺便提一句。我真的是mmap上面的意思。您从 malloc 或任何其他分配功能获得的内存保护也不是您可以触及的。如果你想完全控制你的内存映射，不要使用 libc 也不要做动态链接。
最干净的方法是处理 libc 中出现的 SIGSEGV。但我怀疑是否有这样的方法。
实际上，可以处理由 C 库代码引起的 SIGSEGV 。我确实会处理它们。不能处理的 SIGSEGV 是在处理程序函数本身内或在执行mprotectionVMA 的函数内发生的。
那么，在我保护它们之前，有没有知道这些区域是什么？或者至少有一种方法可以知道 stdarg.h 选择放置 reg_save_area 的位置？
除了@Art 的建议之外，没有办法知道 libc 创建了哪些区域，但我的问题的解决方案是跳过对处理程序本身正在使用的页面的保护，或者是设置整体保护机制。
PS。我不认为这是对我的问题的回答，因为它根本没有回答我提出的问题。它解决了我最初的问题，这就是我分享它的原因。