gcc - 为什么 TI starterware 示例在使用 CodeSourcery gcc 编译时不能正确清除 BSS 段

Question

我在运行 TI AM3359arm 的 beaglebone 时遇到了严重的问题。我正在使用 code sourcery 来编译代码。我尝试编译其中一个示例，称为 enet_lwip，它使用轻量级 IP (lwip) 来提供 http 服务器。

应用程序在某个时刻崩溃了。通过调试我发现，正是这段代码负责:

unsigned int lwIPInit(LWIP_IF *lwipIf)
{

    struct ip_addr ip_addr;

    struct ip_addr net_mask;

    struct ip_addr gw_addr;

    unsigned int *ipAddrPtr;

    static unsigned int lwipInitFlag = 0;

    unsigned int ifNum;

    unsigned int temp;

    /* do lwip library init only once */
    if(0 == lwipInitFlag)
    {
        lwip_init();
    }

一件非常有趣的事情发生在这上面:人们会期望，lwipInitFlag 被初始化为0，因此函数调用 lwip_init() ;

好吧，即使是第一次调用 lwIPInit 函数时也不会发生这种情况。原因是变量 lwipInitFlag 没有设置为 0。

我想知道这是为什么。如果这样的初始化出现在代码中，编译器应该生成序列以将其置空。但可能是因为它前面有 static 修饰符，所以它保持“原样”。为什么？

lwipInitFlag 位于 .bss 链接器部分，它指向 DDR 内存。我如何确保此类静态分配得到初始化？

目前我将破解 lwIP 的代码以查看它是否有效，但这只是对我的警告，库中某处可能有另一个静态声明的变量，这些变量未被初始化。

任何提示如何解决这个问题？

---

为此添加更多信息:在您富有成效的提示之后，我认为我对它的工作方式更加困惑。所以:确实，我没有调用/链接 crt*.o。另一方面，TI starterware 平台包含初始化 asm 源，它执行 BSS 清理。它在地址 _bss_start 和 _bss_end 之间执行。

在查看链接描述文件时，一切看起来都很普通:

SECTIONS
{

        . = 0x80000000;
        . = ALIGN(4);
        .startcode     :
        {
               *init.o      (.text)
        }

        . = ALIGN(4);
        .text      :
        {
                *(.text)
        }

        . = ALIGN(4);

        .data :
        {
                *(.data)
        }

        . = ALIGN(4);

        _bss_start = .;
        .bss :
        {
                *(.bss)
        }
        . = ALIGN(4);

        _bss_end = .;

        _stack = 0x87FFFFF8;
}

所以 _bss_start 是 BSS block 之前的地址，而 _bss_end 是 block 的末尾。 问题在于 Codesourcery 生成了什么 map 。

在生成的映射文件中查看 BSS 的末尾时，我可以看到:

 COMMON         0x80088f0c      0x200 ../binary/armv7a/gcc/am335x/system_config/Debug/libsystem_config.a(interrupt.o)
                0x80088f0c                fnRAMVectors
                0x8008910c                . = ALIGN (0x4)
                0x8008910c                _bss_end = .
                0x87fffff8                _stack = 0x87fffff8
LOAD ../binary/armv7a/gcc/am335x/drivers/Debug/libdrivers.a
LOAD ../binary/armv7a/gcc/utils/Debug/libutils.a
LOAD ../binary/armv7a/gcc/am335x/beaglebone/platform/Debug/libplatform.a
LOAD ../binary/armv7a/gcc/am335x/system_config/Debug/libsystem_config.a
LOAD /opt/CodeSourcery/arm-none-eabi/lib//libc.a
LOAD /opt/CodeSourcery/lib/gcc/arm-none-eabi/4.5.2//libgcc.a
LOAD ../binary/armv7a/gcc/am335x/drivers/Debug/libdrivers.a
LOAD ../binary/armv7a/gcc/utils/Debug/libutils.a
LOAD ../binary/armv7a/gcc/am335x/beaglebone/platform/Debug/libplatform.a
LOAD ../binary/armv7a/gcc/am335x/system_config/Debug/libsystem_config.a
LOAD /opt/CodeSourcery/arm-none-eabi/lib//libc.a
LOAD /opt/CodeSourcery/lib/gcc/arm-none-eabi/4.5.2//libgcc.a
OUTPUT(Debug/bbdidt.out elf32-littlearm)

.bss.pageTable  0x8008c000     0x4000
 .bss.pageTable
                0x8008c000     0x4000 Debug/enetLwip.o

.bss.ram        0x80090000        0x4
 .bss.ram       0x80090000        0x4 Debug/lwiplib.o

显然有“东西”。 在_bss_end之后还有一个BSS段，里面有很多应该清零的东西，但是没有清零，因为清零在_bss_end给出的地址处完成。

这样做的可能原因是，pageTable 是静态声明的并且需要有 16kiB 边界地址:

static volatile unsigned int pageTable[4*1024] __attribute__((aligned(16*1024)));

因此，由于最后一个链接器声明的 BSS 段和 pageTable 之间存在间隙，它将 _bss_end 放在 bss 段的中间。

现在的问题是，如何告诉链接器(我正在为这个 arm-none-eabi-ld 使用)_bss_end 应该真正位于 BSS 的末尾而不是中间的某个地方？

非常感谢

Answer 1

没有 statics 被初始化的事实让我想知道:你的启动代码是怎么来的？执行初始化需要此代码。

参见 http://doc.ironwoodlabs.com/arm-arm-none-eabi/html/getting-started/sec-cs3-startup.html - 第 5.2.3 节说:

---

C启动函数声明如下:

void __cs3_start_c (void) __attribute__ ((noreturn));

此函数执行以下步骤:

• 通过复制内容来初始化所有类似 .data 的部分。例如，ROM 配置文件链接描述文件使用此机制从只读数据程序镜像初始化 RAM 中的可写数据。
• ...等等

---

听起来您可能缺少该代码。