Question

我遇到了运行TI AM3359arm的beaglebone的严重问题。我正在使用代码源代码来编译代码。我尝试编译一个名为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入门级产品平台包含初始化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块之前是地址，而_bss_end在块的末尾是。 问题在于代码源生成的地图。

在生成的地图文件中查看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

初始化 no 静态的事实让我想知道：你是如何通过启动代码来的？执行初始化需要此代码。

见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中的可写数据。
...... etc

听起来你可能缺乏这段代码。

Answer 2

感谢所有这些评论。这对我来说几乎是一个侦探工作。最后，我更改了链接器脚本以获得类似这样的内容：

SECTIONS
{

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

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

        . = ALIGN(4);

        .data :
        {
                *(.data)
        }

        . = ALIGN(4);

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

        _bss_end = .;

        _stack = 0x87FFFFF8;
}

所以我基本上迫使链接器将所有以 COMMON 和 .bss。开头的子段包含在BSS段中。

这显然解决了这个问题，因为链接器现在生成了正确的映射，它将_bss_end指针真正放在BSS段的最后一个地址。

所以我的软件现在运行正常，让PHY运行。我仍然无法获取DHCP，但我想这是未初始化的.data段的问题。 LwIP在某些地方使用静态分配

static u32_t xid = 0xABCD0000;

进入.data段，但显然它没有初始化，因此我无法获得任何DHCP响应......但这是另一个故事

感谢所有

为什么TI初始化软件示例在使用CodeSourcery gcc编译时无法正确清除BSS段

2 个答案: