可以弱符号库中链接过程中得到解决？ [英] Can weak symbol be resolved among libraries during linking?

问题描述

我的方案是关于交叉编译到的Arduino由于（ARM目标），但我想这是一个通用的C弱符号的问题。

My scenario is about cross-compiling to a Arduino Due (ARM target), but I guess it's a generic C weak symbol problem.

我要打破我的固件分为3部分：
 1.硬件库（CMSIS，中间件） - > libHardware.a
 2.实时OS库 - > libOS.a
 3.应用code - > Output.elf联系到上述

I want to break my firmware into 3 parts: 1. The hardware library (CMSIS, Middleware) -> libHardware.a 2. Realtime OS library -> libOS.a 3. Application code -> Output.elf linked to above.

引用的CMSIS实施已申报如下：

the referenced CMSIS implementation has declared the followings:

void SysTick_Handler    ( void ) __attribute__ ((weak, alias("Dummy_Handler")));
// ...and a few dozen IRQ handler hook skipped for brevity

在CMSIS设计理念是让应用程序code执行和处理一些IRQ的选择。

The idea of the CMSIS design is to have the Application Code implementing and handling some of IRQ selectively.

有关libHardware.a纳米报道

nm reports for libHardware.a

startup_sam3xa.o:
00000000 W SysTick_Handler
...

和在我的情况，我想实现在libOS.a论文IRQ处理程序。

And in my scenario, I would like to implement theses IRQ handlers in the libOS.a.

我执行无效SysTick_Handler（无效），纳米报告：

I implement void SysTick_Handler(void), nm reports:

cortex_handlers.o:
00000000 T SysTick_Handler
....

然后我将它们关联起来，这基本上可以归结为

Then I link them together, which basically boils down to

g++ -o app.elf -Wl,--start-group app.o libHardware.a libOS.a -Wl,--end-group

（分组是必要的，因为操作系统依赖于低级硬件功能。五金需要调用由OS provdided的IRQ / main（）函数）

(Grouping is necessary because OS depends on the low level Hardware function. And Hardware need to calls the IRQ/main() function provdided by the OS)

纳米报告：

...
00080124 W SysTick_Handler
...

它依然疲软！我希望它用在libOS.a定义的符号强要。
最后，系统定时器没有被处理，这当然会导致灾难性的失败。

It's still weak! I expect it to be using the strong symbol defined in the libOS.a. At the end, SysTick isn't handled, which of course leads to catastrophic failure.

在另一方面，如果我不声明为弱libHardware / startup_sam3xa.c，一切工作正常。
如果我选择在app / app.c实施SysTick_Handler，它是紧密联系在一起了。

On the other hand, if I don't declare them as weak in libHardware/startup_sam3xa.c, everything works fine. If I choose to implement SysTick_Handler in the app/app.c, it's strongly linked too.

所以我的问题是：如何能libOS.a实现了libHardware.a定义的弱处理？
或者，这将是在这些固件开发方案的最佳实践？

So my question is: how could libOS.a implements the weak handler defined in libHardware.a? Or what would be the best practice in these firmware development scenarios?

推荐答案

在定义 SysTick_Handler 在 cortex_handlers.c 它定义了正常入口点。但它会覆盖弱符号，只有当链接到达链接特定对象文件（从libOS.a）的请求。

When you define the SysTick_Handler in cortex_handlers.c it defines the normal entry point. But it will overwrite the weak symbol only when the linker gets a request to link the specific object file (from libOS.a).

该libHardware.a通常定义了 SysTick_Handler 引用的中断向量表。这是本实际的名字来源于在游戏中唯一的指针。 （对于ARM，它只是在向量表中的一个条目。）相同的库已经提供了弱符号。因此，链接器不会的搜索的该符号了。当你想覆盖符号 cortex_handlers.c 您需要引用任何符号在该文件中导致链接器使用 cortex_handlers.o 。这将揭开序幕弱符号。

The libHardware.a usually defines the Interrupt vector table where the SysTick_Handler is referenced. This is the only pointer this actual name comes in the game. (For the ARM it's just an entry in the vector table.) The same library already provides a weak symbol. Therefore the linker doesn't search for that symbols anymore. When you want to overwrite the symbol in cortex_handlers.c you need to reference any symbol in that file causing the linker to use cortex_handlers.o. That will kick off the weak symbol.

// cortex_handlers.c

void SysTick_Handler()
{
}

int link_my_cortex_handlers_file;

只是参考某处符号 link_my_cortex_handlers_file 。

这篇关于可以弱符号库中链接过程中得到解决？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！