assembly 在QEMU中，C中用于操作位字段的汇编代码行为怪异

我在做2018版MIT 6.828时遇到了一些奇怪的事情，该实验室在QEMU上运行，模拟80386 CPU：
我想做的是初始化INTEL 82540 EM芯片（也称为E1000）的接收过程。我基本上只是写一些字节到设备的寄存器。
首先，我定义了一个带有位字段的结构，因为它实际上是硬件中的寄存器：

struct rx_addr_reg {
    // low 32 bit
    unsigned ral : 32;  // 0 - 31
    // high 32 bit
    unsigned rah : 16;  // 0 -15
    unsigned as  : 2;   // 16 - 17
    unsigned rs  : 13;  // 18 - 30
    unsigned av  : 1;   // 31
};

我决定通过C宏使用它：

#define E1000_RA       0x05400  /* Receive Address - RW Array */
#define E1000_RAH_AV  0x80000000        /* Receive descriptor valid */

#define E1000_GET_REG(base,reg) \
{   ((void*)(base) + (reg))    }
#define E1000_SET_RECEIVE_ADDR_REG(addr,as,rs,av) (struct rx_addr_reg)\
{   (addr >> 16) & 0xffffffff, (addr) & 0xffff, \
    (as) & 0x3, (rs) & 0x1fff, (av) & 0x1 }

然后在我的.c文件中，我尝试访问并初始化寄存器：

// Receive Initialization
    // Program the Receive Address Registers (RAL/RAH) with the desired Ethernet addresses
    struct rx_addr_reg* rar = (struct rx_addr_reg*) E1000_GET_REG(e1000_va, E1000_RA);
    *rar = E1000_SET_RECEIVE_ADDR_REG(0x120054525634, 0x0, 0x0, 0x1);

我期望在内存中看到的rar是这样的：

Memory address: content
0x????????: 0x12005452 0x80005634

然而，结果却是：

Memory address: content
0x????????: 0x12005452 0x00000080

这很奇怪，所以我在GDB中查看了一下程序：

+ target remote localhost:26000
The target architecture is assumed to be i8086
[f000:fff0]    0xffff0: ljmp   $0xf000,$0xe05b
0x0000fff0 in ?? ()
+ symbol-file obj/kern/kernel
(gdb) br e1000.c:64
Breakpoint 1 at 0xf0107470: file kern/e1000.c, line 64.
(gdb) si
[f000:e05b]    0xfe05b: cmpl   $0x0,%cs:0x6ac8
0x0000e05b in ?? ()
(gdb) c
Continuing.
The target architecture is assumed to be i386
=> 0xf0107470 <pci_e1000_attach+264>:   movl   $0x60200a,0x410(%eax)

Breakpoint 1, pci_e1000_attach (pcif=0xf012af10) at kern/e1000.c:64
64          *(uint32_t*)((char*)e1000_va + E1000_TIPG) |= 10 | 8 << 10 | 6 << 20;
(gdb) si
=> 0xf010747a <pci_e1000_attach+274>:   movl   $0x12005452,0x5400(%eax)
82          *rar = E1000_SET_RECEIVE_ADDR_REG(0x120054525634, 0x0, 0x0, 0x1); //0x525400123456 0x120054525634
(gdb)
=> 0xf0107484 <pci_e1000_attach+284>:   movw   $0x5634,0x5404(%eax)
0xf0107484      82          *rar = E1000_SET_RECEIVE_ADDR_REG(0x120054525634, 0x0, 0x0, 0x1); //0x525400123456 0x120054525634
(gdb)
=> 0xf010748d <pci_e1000_attach+293>:   andb   $0xfc,0x5406(%eax)
0xf010748d      82          *rar = E1000_SET_RECEIVE_ADDR_REG(0x120054525634, 0x0, 0x0, 0x1); //0x525400123456 0x120054525634
(gdb) x/2xw $eax + 0x5400
0xef809400:     0x12005452      0x00005634
(gdb) si
=> 0xf0107494 <pci_e1000_attach+300>:   andw   $0x8003,0x5406(%eax)
0xf0107494      82          *rar = E1000_SET_RECEIVE_ADDR_REG(0x120054525634, 0x0, 0x0, 0x1); //0x525400123456 0x120054525634
(gdb) x/2xw $eax + 0x5400
0xef809400:     0x12005452      0x00000034
(gdb) si
=> 0xf010749d <pci_e1000_attach+309>:   orb    $0x80,0x5407(%eax)
0xf010749d      82          *rar = E1000_SET_RECEIVE_ADDR_REG(0x120054525634, 0x0, 0x0, 0x1); //0x525400123456 0x120054525634
(gdb) x/2xw $eax + 0x5400
0xef809400:     0x12005452      0x00000000
(gdb) si
=> 0xf01074a4 <pci_e1000_attach+316>:   movl   $0x1,0xc(%esp)
86          cprintf("[RAH:RAL] [av]: [%x:%x] [%x]\n", rar->rah, rar->ral, rar->av);
(gdb) x/2xw $eax + 0x5400
0xef809400:     0x12005452      0x00000080
(gdb)

以下是我无法理解的几点：
1.汇编代码尝试将0x5406(%eax)中的字节与0xfc进行 AND 运算，但实际上似乎清除了0x5405中的字节。

(gdb)
=> 0xf010748d <pci_e1000_attach+293>:   andb   $0xfc,0x5406(%eax)
0xf010748d      82          *rar = E1000_SET_RECEIVE_ADDR_REG(0x120054525634, 0x0, 0x0, 0x1); //0x525400123456 0x120054525634
(gdb) x/2xw $eax + 0x5400
0xef809400:     0x12005452      0x00005634
(gdb) si
=> 0xf0107494 <pci_e1000_attach+300>:   andw   $0x8003,0x5406(%eax)
0xf0107494      82          *rar = E1000_SET_RECEIVE_ADDR_REG(0x120054525634, 0x0, 0x0, 0x1); //0x525400123456 0x120054525634
(gdb) x/2xw $eax + 0x5400
0xef809400:     0x12005452      0x00000034

1.然后，ANDW 出现了问题，似乎很清楚0x5404(%eax)处的字节：

(gdb) si
=> 0xf0107494 <pci_e1000_attach+300>:   andw   $0x8003,0x5406(%eax)
0xf0107494      82          *rar = E1000_SET_RECEIVE_ADDR_REG(0x120054525634, 0x0, 0x0, 0x1); //0x525400123456 0x120054525634
(gdb) x/2xw $eax + 0x5400
0xef809400:     0x12005452      0x00000034
(gdb) si
=> 0xf010749d <pci_e1000_attach+309>:   orb    $0x80,0x5407(%eax)
0xf010749d      82          *rar = E1000_SET_RECEIVE_ADDR_REG(0x120054525634, 0x0, 0x0, 0x1); //0x525400123456 0x120054525634
(gdb) x/2xw $eax + 0x5400
0xef809400:     0x12005452      0x00000000

1.最后，它 ORBs在0x5404(%eax)的字节，它应该or与0x5407(%eax)

(gdb) si
=> 0xf010749d <pci_e1000_attach+309>:   orb    $0x80,0x5407(%eax)
0xf010749d      82          *rar = E1000_SET_RECEIVE_ADDR_REG(0x120054525634, 0x0, 0x0, 0x1); //0x525400123456 0x120054525634
(gdb) x/2xw $eax + 0x5400
0xef809400:     0x12005452      0x00000000
(gdb) si
=> 0xf01074a4 <pci_e1000_attach+316>:   movl   $0x1,0xc(%esp)
86          cprintf("[RAH:RAL] [av]: [%x:%x] [%x]\n", rar->rah, rar->ral, rar->av);
(gdb) x/2xw $eax + 0x5400
0xef809400:     0x12005452      0x00000080

1.顺便说一句，当我尝试打印0x5400(%eax)的字节时，为什么gdb拒绝这样做，而只显示4 bytes对齐的字节的内容？

(gdb) x/xw $eax+0x5404
0xef809404:     0x00000034
(gdb) x/xw $eax+0x5406
0xef809406:     0x00000034
(gdb) x/xb $eax+0x5406
0xef809406:     0x34
(gdb) x/xb $eax+0x5404
0xef809404:     0x34

有一点我认为它可以解决问题，但我不确定：我定义的结构是一个8字节长，系统运行在32位下。因此，如果不允许设备写入位字段，并且仅允许写入整个4字节，则该问题可能是合理的。
真的很感谢你的回答！

该硬件定义其寄存器为32位宽。这意味着你需要一次读写32位。你的C代码没有做任何事情来确保这一点发生;编译器假设当你对指向结构体的指针进行操作时，你是在阅读普通的RAM。对于RAM，通过一次阅读少于32位来更新32位值中的子字段是很好的，这就是编译器生成的代码所做的，具有其字节和字操作。但是，这在设备寄存器上不能正常工作。（QEMU的实现将忽略字节和字访问尝试;当您尝试通过gdbstub访问设备时，您也可以看到这一点。）
因此，你不能只定义一个结构体，它的位域与规范中的寄存器一致，并期望写入单个位域就能正确工作。如果要更新寄存器中的单个字段，则应读取整个32位寄存器，更新值的相关部分，然后再次写回整个32位值。（通常您希望一次更新所有字段，在这种情况下，您只需写入完整的新值，而无需先执行读取操作。
您还需要确保编译器不会认为这只是RAM，因此它可以愉快地重新排序，合并或删除更新。就我个人而言，我喜欢Linux内核定义函数的方法，这些函数用于进行访问，最终归结为asm加载和存储，这样就可以100%清楚地知道生成的代码要做什么;也有其他方法。

assembly 在QEMU中，C中用于操作位字段的汇编代码行为怪异

1条答案

相关问题

热门标签

最新问答