L6305W: Image does not have an entry point. (Not specified or not set due to multiple choices.)

做项目的时候遇到此问题，现在终于解决了，把过程罗列出来供大家参考。

1. 简单介绍一下项目。这个项目是为嵌入式平台开发的，不同的功能模块分别编译成独立库文件a.lib, b.lib, c.lib，d.lib...

最后和RTOS编译成的诸多.o文件链接在一起生成一个bootable 的arm平台运行的bin文件。

ENTRY POINT在 RTOS中的int.s中指定。

编译链接步骤简单介绍如下：

(1)分别生成各个.c文件的目标文件

tcc -c -li -fK -dwarf2 -g+ -O0 -apcs /interwork -Ez -Ec -o binaries/obj/a_file1.o a_file1.c

tcc -c -li -fK -dwarf2 -g+ -O0 -apcs /interwork -Ez -Ec -o binaries/obj/a_file1.o a_file2.c

tcc -c -li -fK -dwarf2 -g+ -O0 -apcs /interwork -Ez -Ec -o binaries/obj/a_file1.o a_file3.c

tcc -c -li -fK -dwarf2 -g+ -O0 -apcs /interwork -Ez -Ec -o binaries/obj/a_file1.o a_file4.c

.....

(2)各个模块分别链接成库文件

armar -rc ./binaries/lib/a.lib ./binaries/obj/a_file1.o ./binaries/obj/a_file2.o ./binaries/obj/a_file3.o ./binaries/obj/a_file4.o

类似方法分别生成b.lib, c.lib, d.lib....

(3)最后生成bootable bin wlan_arm.bin文件，出现warning.

armlink -d -strict -s -callgraph -Xref -map -list ../../bin/wlan_arm.map -o ../../bin/wlan_arm.axf -scatter link_ram.ld obj/syapp.obj obj/symain.obj /lib/a.lib /lib/b.lib /lib/c.lib /lib/d.lib

fromelf -bin ../../bin/wlan_arm.axf ../../bin/wlan_arm.bin

L6305W: Image does not have an entry point. (Not specified or not set due to multiple choices.)

Finished: 0 information, 1 warning and 0 error messages.

2. 问题分析

2.1问题出现

模块d升级后出现了此L6305W warning. 由链接器的文档说明，要么没指定这个ENTRY POINT, 要么就是指定了多个ENTRY POINT. 查看armlink -map生成的映像文件，看到多了一个默认的entry point " __main()".

int.o中我们已经指定了ENTRYPOINT, main()函数应该是编译器自己默认编译成loadable的bin文件的时候默认的普通ENTRY POINT. 普通的loadable的bin文件是需要操作系统(OS)为其分配内存并加载到内存中的，其中上下文的地址都是相对地址，需要OS为其分配内存后，加上分配内存的基址才是它真正的运行地址。但是bootable的bin文件就不同了，它的上下文中的地址直接就是实际运行时刻的内存地址。其中细节在此不多介绍，而且不同的OS，不同的CPU, 对loadable的文件应该有不同的地址处理。如果有对细节了解更系统，更深刻的朋友，请赐教。

===============================================

Memory Map of the image

Image entry point : Not specified.

Load Region LOAD_RAM (Base: 0x10000000, Size: 0x00278544, Max: 0xffffffff, ABSOLUTE)

Execution Region text (Base: 0x10000000, Size: 0x00238490, Max: 0xffffffff, ABSOLUTE)

Base Addr Size Type Attr Idx E Section Name Object

0x10000000 0x00000040 Code RO 3785 * vectors int.o(plus_specific.lib)

0x10000040 0x000000dc Code RO 13462 * !!! __main.o(c_t__un.l)

=====================================================

在此我也有几个问题不是非常明白。比如，ENTRY POINT对于编译器的真正意义是什么？是不是，编译器会从这个ENTRY POINT开始找寻链接关系，只要是从此处开始逐层调用引用到得文件就链接到bin文件中，引用不到的自然就不链接进来了。

还有就是ENTRY POINT是不是一定放在地址的最开始？

再者就是，对于loadable的文件，有没有办法自己指定ENTRY POINT，而不是用默认的main()？

2.2发现原因

模块d之前没有使用过strncasecmp()，但是升级后却使用了，虽然在自己本身模块中已经定义了此函数。但是从armlink -Xref 生成的引用关系中明确看到它使用的是c.lib中定义的strncasecmp()。（当然还有其他函数也出现类似情况，现在仅跟踪此线索来解决问题。）strncasecmp() 在c_file1.o中定义，此文件中其他函数引用到exit.o, exit.o 引用到kernel.o, kernel.o引用到c_file3.o, c_file3.o引用到__main，这个应该就是默认的ENTRY POINT了。于是俺们滴bin文件中就多了个ENTRY POINT.（引用关系参考下面Section Cross References）

如果将链接时的顺序倒过来，即d.lib 在c.lib之前，那么d.lib就会乖乖用自己的strncasecmp()了。

================================================================================

Section Cross References

d_file2.o(.text) refers to c_file1.o(.text) for strncasecmp

c_file1.o(.text) refers to exit.o(.text) for exit

exit.o(.text) refers to kernel.o(.text) for __rt_exit

kernel.o(.text) refers to c_file3.o(.text) for main

c_file3.o(.text) refers (Special) to __main.o(!!!) for __main

================================================================================

3. 问题解决

看了下引用关系，确定像c_file3.o此一类的文件并没有真正用到，只是automake的时候把此模块中的文件全部编译了才引入到c.lib中。于是，重写Makefile, 仅编译指定的几个.c文件到c.lib中, c_file3.o不再出现在c.lib中。

自此，天下太平。

（当然，如果c_file3.o中的函数，你需要引用，那么就只能换个方法了。）