背景
我试图利用我的STM32设备上位于地址0x40006000的特殊部分的SRAM。我在ST的示例代码中看到的一种做法是仅仅创建指向其内存的值的指针。我想要做的是让链接器为我管理该部分中的静态分配。为什么objcopy排除一个部分而不是另一个部分？
基本上，我从一些事情是这样的：
static uint16_t *buffer0 = ((uint16_t *)0x40006000);
static uint16_t *buffer1 = ((uint16_t *)0x40006080);
为了这样的事情（我认为这是远不易破碎，而不是作为哈克，虽不如便携式）：
#define _PMA __attribute__((section(".pma"), aligned(2)))
static uint16_t _PMA buffer0[64];
static uint16_t _PMA buffer1[64];
为了做到这一点，我修改了我的链接描述文件，在0x40006000上有一个名为“PMA”的新内存，我在其中找到了“.pma”部分，如下所示：
MEMORY
{
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 64K
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 20K
PMA (xrw) : ORIGIN = 0x40006000, LENGTH = 1024 /* This is the memory I added */
}
SECTIONS
{
.text
{
..blah blah blah..
} > FLASH
...more sections, like rodata and init_array..
/* Initialized data goes into RAM, load LMA copy after code */
.data
{
..blah blah blah with some linker symbols to denote the start and end..
} >RAM AT> FLASH
.bss
{
..blah blah blah..
} >RAM
.pma /* My new section! */
{
_pma_start = .;
. = ALIGN(2);
*(.pma)
*(.pma*)
} >PMA
}
会发生什么
因此，这似乎是所有罚款和花花公子，我的东西编译和地图显示我buffer0和buffer1确实放置在0x40006000和0x40006080。这里是我的Makefile文件的最后一位的输出：
arm-none-eabi-gcc obj/usb_desc.o obj/usb_application.o obj/osc.o obj/usb.o obj/main.o obj/system_stm32f1xx.o obj/queue.o obj/list.o obj/heap_1.o obj/port.o obj/tasks.o obj/timers.o obj/startup_stm32f103x6.o -TSTM32F103X8_FLASH.ld -mthumb -mcpu=cortex-m3 --specs=nosys.specs -Wl,-Map,bin/blink.map -o bin/blink.elf
arm-none-eabi-objdump -D bin/blink.elf > bin/blink.lst
arm-none-eabi-size --format=SysV bin/blink.elf
bin/blink.elf :
section size addr
.isr_vector 268 134217728
.text 13504 134218000
.rodata 44 134231504
.ARM 8 134231548
.init_array 8 134231556
.fini_array 4 134231564
.data 1264 536870912
.jcr 4 536872176
.bss 1348 536872180
._user_heap_stack 1536 536873528
.pma 256 1073766400
.ARM.attributes 41 0
.debug_info 26748 0
.debug_abbrev 5331 0
.debug_aranges 368 0
.debug_line 5274 0
.debug_str 8123 0
.comment 29 0
.debug_frame 4988 0
Total 69146
arm-none-eabi-objcopy -R .stack -O binary bin/blink.elf bin/blink.bin
我看到.pma使用了256个字节，就如我所料。地址看起来也是正确的。现在，当我ls的bin目录，我迎接这样的：
-rwxr-xr-x 1 kevin users 939548800 Nov 2 00:04 blink.bin*
-rwxr-xr-x 1 kevin users 221528 Nov 2 00:04 blink.elf*
这bin文件是什么，我加载到通过OpenOCD的我芯片的闪存。它是从0x08000000开始的闪光的图像。
旁注：在我意识到它有多大之前，我实际上已经试图将这个bin文件加载到我的芯片上......这显然不起作用。
这里就是我得到的，当我删除PMA部分：
arm-none-eabi-size --format=SysV bin/blink.elf
bin/blink.elf :
section size addr
.isr_vector 268 134217728
.text 13504 134218000
.rodata 44 134231504
.ARM 8 134231548
.init_array 8 134231556
.fini_array 4 134231564
.data 1392 536870912
.jcr 4 536872304
.bss 1348 536872308
._user_heap_stack 1536 536873656
.ARM.attributes 41 0
.debug_info 26748 0
.debug_abbrev 5331 0
.debug_aranges 368 0
.debug_line 5274 0
.debug_str 8123 0
.comment 29 0
.debug_frame 4988 0
Total 69018
和文件大小是完全按照我期望：
-rwxr-xr-x 1 kevin users 15236 Nov 2 00:09 blink.bin
-rwxr-xr-x 1 kevin users 198132 Nov 2 00:09 blink.elf
问题
据我了解，这里发生的是objcopy刚刚从0x08000000到0x400060FF复制到该bin文件中的所有内容。这显然不是我想要发生的事情。我预计它会复制闪光灯。
现在，很明显，我可以只在我的objcopy命令上说-R .pma，一切都会很开心。但是，我很好奇的是objcopy知道不要将.data复制到二进制映像中。我注意到运行objcopy -R .data与运行objcopy的结果完全相同。与.bss一样的东西。这告诉我，这是不是在链接脚本的命令AT（这是唯一的真正的区别我可以看到.data之间.bss）
我能做些什么让我的.pma部分行为相同的方式为.data或.bss from objcopy的角度？或许我正在使用的中间精灵文件中有.data/.bss有一些有趣的事情（请参阅上面的链接器命令生成elf文件）？