我在beaglebone运行TI AM3359arm时遇到了严重的问题。我正在使用代码源代码来编译代码。我尝试编译其中一个示例，名为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块之前的地址，并且_bss_end是在该块的末尾处的问题在于Codesourcery生成什么映射。
当在生成的地图文件中查看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的末尾，而不是中间的某个位置？
非常感谢
nostatics被初始化的事实让我想知道：你的启动代码是怎么来的？此代码是执行初始化所必需的。
请参阅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中的可写数据
- 。。。等等
听起来你可能缺少那个代码。
感谢您的评论。对我来说，这几乎是一部侦探作品。最后，我更改了链接器脚本，得到了如下内容：
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;
}
因此，我基本上强制链接器在BSS段中包含所有以COMMON和.BSS.开头的子段
这显然解决了这个问题，因为链接器现在生成了正确的映射，从而将_bss_end指针真正放置到bss部分的最后一个地址。
所以我的软件现在运行正常，PHY运行。我仍然无法获取DHCP，但我想这是一个未初始化的.data段的问题。LwIP在某些地方使用静态分配作为
static u32_t xid = 0xABCD0000;
它正在进入.数据段，但显然它没有初始化，因此我无法获得任何DHCP电源。。。但这是另一个故事
感谢所有