假设有4个线程在多核x86处理器的4个独立内核上运行，并且它们不共享任何数据，是否有可能在程序上使4个内核使用共享L2高速caching的单独的和预定义的部分。
我知道你可以使用ptrace来捕获一个系统调用。 但是我想要做的是忽略一个系统调用。 因此， ptrace可以捕获一个系统调用，查看它的编号，如果这个编号是一个必须被忽略的系统调用，那么ptrace会停止系统调用继续执行或者立即返回系统调用。 重点是我们应该使应用程序通过使用ptrace来忽略特定的系统调用。
当一个系统调用返回时，我得到％eax中的系统调用返回值，但是在入口处得到-38，这是hex的0xFFFFFFDA。 这是为了写/读。 这个数字是多less？ 它可以用来安全区分出入口吗？
我发现当我们使用嵌套函数时 ，GCC需要一个可执行的栈来存放蹦床代码 。 但是，下面的代码在使用gcc编译时不会显示可执行堆栈。 （我用execstack来validation堆栈是否可执行） #include <stdio.h> #include <unistd.h> int main() { int add( int a, int b) { return a + b; } return add(2, 3); } 为什么这不会导致可执行堆栈？ 如果它不应该，那么有人可以给一个代码构造的例子，提供一个可执行的堆栈？
我的问题的理由是， Starman似乎相信GRUB Legacy作者的解释 （请参阅以下莫名其妙的代码： 7C4B EA507C0000 JMP 0000:7C50 ; Long Jump to the next instruction ; because some bogus BIOSes jump to ; 07C0:0000 instead of 0000:7C00. 当我执行Intel指定的algorithm来构build第一个内存引用的有效地址时，我将07C0乘以16（实际上左移四位或一个半字节）。 然后我加上偏移量：0000，得到小数地址31,744。 如果我左移了第二个内存引用四位的段，我仍然有0000：和偏移量：7C00仍然寻址位置31,744。 所以我的直觉反应是这个GRUB Legacy引导扇区代码的作者拉我们的腿。 不pipe任何BIOS的内存引用的forms，如果有效地址计算为十进制31,744，那么这个跳远似乎没有问题解决。 假设代码的作者只是以一种看起来与正确的物理位置相同的方式表示伪造的物理内存位置，我开始考虑如何处理一个发送错误地址的BIOS。 五字节跳远似乎不是解决任何问题的方法。 五个NOP将用于相同的目的（事实上，简单地开始引导扇区代码提前五个字节，并且消除跳远将具有与跳到下一个指令的跳转相同的效果）。 如果BIOS跳转到正确的位置（7C00），没问题。 如果BIOS跳转到7C00以上的位置，那么在7C00加载的代码就不能解决这个问题。 如果BIOS跳转到7C00和7C4B之间的某个位置，那么存储在该区域的数据（或者解释为字节丢失的指令）可能会导致崩溃。 如果BIOS跳转到7C4B，TEST指令将被覆盖（通过跳转），JNZ到7C54将根据BIOS中执行的最后一个math运算来执行。 对于7C4B以下的BIOS跳转，错误alignment的指令可能会导致崩溃。 祝你好运，引导扇区代码的一部分将被执行。 这种执行的结果将取决于BIOS跳到的“假”内存地址。 那么这个引导扇区代码的作者拉着我们的腿“故障BIOS跳到错误的位置”的故事？ 我在Luke Luo的博客中注意到，GRUB2引导扇区虽然不同于GRUB Legacy引导扇区，但保留了这种莫名其妙的跳跃 。 因此，如果GRUB Legacy引导扇区的原作者正在为我们开玩笑，这是一个非常成功的笑话（它已经完全重写了GRUB）。 我还剩下一些select，相信对一些未命名的BIOS有一个令人难以置信的断言，并且解决这个问题似乎实际上什么都不做， 或者相信原始引导部门的作者在为我们开玩笑。 卢克罗似乎接受了写入7P66和7C67的NOP指令，作为他没有跳到错误位置的BIOS的证据。 由Linux Mint […]
Linux如何同时32位和64位？ 或者是在glibc中处理的东西？ 我运行CentOS 5.3，它是一个“64位”版本; 虽然我build立了64位和32位的东西。 据我所知，Windows应该有一个32位的仿真器。 Linux是否做同样的事情？ 它在用户空间还是内核空间？ 如果libc处理它，它有点像模拟器，说，我会链接到32位应用程序，但说64位的内核？
有人能解释三种架构之间的区别吗？ 实际上，当我在Linux中构build一个64位应用程序时，我得到一个链接错误： skipping incompatible library.a when searching for library.a 然后我在这个库上使用了objdump -f ，并且得到了下面的输出： ao: file format elf32-x86-64 architecture: i386:x64-32, flags 0x00000011: HAS_RELOC, HAS_SYMS start address 0x00000000 这是否意味着库是32位？ 这是我得到链接错误的原因？
也许这只是我，但是在第二man 2页面上的membarrier似乎毫无意义。 基本上， membarrier()是一个asynchronous内存屏障，给定两个协调的代码片段（让我们调用快速path和慢速path ），可以将障碍的所有硬件成本移动到慢速path ，并保留快速path只有一个编译器障碍1 。 有几种不同的方式来完成membarrier行为，例如发送IPI给每个相关的处理器，或者等待每个处理器上运行的代码被取消调度 – 但是在这里确切的实现细节并不重要。 现在，这是在手册页中给出的示例转换： 原始代码 static volatile int a, b; static void fast_path(void) { int read_a, read_b; read_b = b; asm volatile ("mfence" : : : "memory"); read_a = a; /* read_b == 1 implies read_a == 1. */ if (read_b == 1 && read_a == 0) abort(); […]
假设我已经将gdb附加到一个进程，并且在其内存布局中有一个文件和行号，我想要的内存地址。 如何获得文件x中第n行的内存地址？ 这是在Linux x86上。
我写了一个小c程序： #include <stdio.h> int main() { char s[] = "Hello, world!"; printf("%s\n", s); return 0; } 编译（在我的Linux机器上）： .file "hello.c" .text .globl main .type main, @function main: .LFB0: .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset 6, -16 movq %rsp, %rbp .cfi_def_cfa_register 6 subq $32, %rsp movq %fs:40, %rax movq %rax, -8(%rbp) xorl %eax, %eax movl $1819043144, -32(%rbp) […]