Assembly GDB中寄存器偏移1的可能原因是什么？

微控制器是一个STM32 F767ZI，它包含一个32位的ARM Cortex M7

当设置寄存器的值时，所有寄存器似乎都偏移了1

例如，以下代码：

core.S

.syntax unified
.cpu cortex-m7
.fpu softvfp
.thumb

// Global memory locations
.global vtable
.global reset_handler

 .type vtable, %object
 vtable:
    .word _estack
    .word reset_handler
.size vtable, .-vtable

/*
 * The Reset handler
 */
 .type reset_handler, %function
 reset_handler:
    // The '_estack' value is defined in the linker script
    LDR sp, =_estack
    

    // Dummy values
    LDR r5, =0xDEADBEEF
    MOV r3, #50
    
.size reset_handler, .-reset_handler

.syntax unified
.cpu cortex-m7
.fpu softvfp
.thumb

// Global memory locations
.global vtable
.global reset_handler

 .type vtable, %object
 vtable:
    .word _estack
    .word reset_handler
.size vtable, .-vtable

/*
 * The Reset handler
 */
 .type reset_handler, %function
 reset_handler:
    // The '_estack' value is defined in the linker script
    LDR sp, =_estack
    

    // Dummy values
    LDR r5, =0xDEADBEEF
    MOV r3, #50
    
.size reset_handler, .-reset_handler

linkerscript/stm32-767zi.ld

_estack = 0x20080000;

MEMORY
{
    FLASH ( rx )        : ORIGIN = 0x08000000, LENGTH = 2048K
    RAM ( rxw )         : ORIGIN = 0x20000000, LENGTH = 512K
}

通过运行编译时：

arm-none-eabi-gcc-x汇编程序，带cpp-c-O0-mcpu=cortex-m7-mthumb-Wall core.S-o core.o

然后

arm none eabi gcc core.o-mcpu=cortex-m7-mthumb-Wall-specs=nosys.specs-nostlib-lgcc-T./linkerscript/stm32-767zi.ld-o main.elf

结果：

如您所见，

r6

设置为

0xdeadbeef

，而不是

r5

，这是前面代码中编写的内容。该偏移量与设置的其他两个寄存器相同

我相信链接器脚本的值是正确的，所以我假设问题是由于其他地方的配置不正确造成的

---

因此，我有点不确定如何从这里开始，并询问是否有人对可能出现的问题有任何想法或建议。

好吧，看到大多数评论认为GDB服务器可能存在问题，我决定尝试另一台GDB服务器

结果非常令人高兴：

用于：

core.S

.syntax unified
.cpu cortex-m7
.fpu softvfp
.thumb

// Global memory locations
.global vtable
.global reset_handler

 .type vtable, %object
 vtable:
    .word _estack
    .word reset_handler
.size vtable, .-vtable

/*
 * The Reset handler
 */
 .type reset_handler, %function
 reset_handler:
    // The '_estack' value is defined in the linker script
    LDR sp, =_estack
    

    // Dummy values
    LDR r5, =0xDEADBEEF
    MOV r3, #50
    
.size reset_handler, .-reset_handler

.syntax unified
.cpu cortex-m7
.fpu softvfp
.thumb

// Global memory locations
.global vtable
.global reset_handler

 .type vtable, %object
 vtable:
    .word _estack
    .word reset_handler
.size vtable, .-vtable

/*
 * The Reset handler
 */
 .type reset_handler, %function
 reset_handler:
    // The '_estack' value is defined in the linker script
    LDR sp, =_estack
    

    // Dummy values
    LDR r5, =0xDEADBEEF
    MOV r3, #50
    
.size reset_handler, .-reset_handler

这为我解决了这个问题

最初，我是在Windows上使用的，但是我切换到了GDB，它作为一个插件

看起来问题确实出在GDB服务器上

---

谢谢大家的帮助和建议，非常感谢。

这很奇怪！我以前从未见过这样的事情。也许是JTAG实现中的一个bug？您能提供一些关于JTAG探测器、GDB服务器软件、您正在使用的GDB版本的信息吗？这与问题完全无关，但看起来您正在尝试进行一个非常简单的实现。为了实现这一目标，您可以将负载卸载到sp，因为硬件从矢量中的第一个条目就已经为您完成了加载。请提供一个编译器示例，其中包括未运行到以太中的代码，以及您停止程序以检查registers@old_timer我还在程序末尾添加了一个无限循环，然后停在那里。以前，我只是让它运行到底，然后检查寄存器值。@PeterCordes啊，我的印象是，通过输入

arm none-eabi-GDB

访问的GDB接口是客户端，处理与外部设备的USB连接和“客户端”连接的软件称为服务器？如果不是这样，我道歉。。。我对这一切还不太熟悉。这是对的还是我完全错了？如果是，请纠正我！在这种情况下，

arm none eabi gdb

是客户端。你说的是“在Windows上”使用某些东西，然后改成其他东西，所以我认为你说的是更改客户端。但显然，对于JTAG，GDB服务器也运行在您的桌面上，并处理USB连接。感谢您的澄清，我只在qemu之类的东西上使用了GDB远程调试，其中模拟器是GDB服务器。我甚至不确定是否会有一个带有JTAG设置的“服务器”。