Hello ARM Community,
I am using DS-5 5.18.1. I have a C function which must be compiled inline to decrease latency of an FIQ handler. I referenced following document for syntax:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0472k/chr1359124973480.html
Note that the attribute may accompany the function declaration and/or definition.
I added the attribute to the function declaration as below in example.c:
void foo(void) __attribute__((always_inline));
The following linking error was produced:
L6218E: Undefined symbol foo (referred from example.o). C/C++ Problem
It is important to note that this error was not present before adding the inline attribute. There are no related warnings, nor any other errors. Why would this single change cause the preceding error?
Thank you,
Ryan
Yes, you have accurately recreated the scenario. It is against our code standard to have a function definition in a header file. An alternate solution is to move the declaration of foo into the same file as it is called as done in your first reply. This is not preferable in order to preserve code modularity. Is there another solution?
Hi Ryan,
the tricky part here is that you need to have the definition of the function available when compiling main.c otherwise armcc would ignore the always_inline statement and would put a BL to that function. A possible alternative, from my point of view less clear, is to include the source file instead of the header as:
#include "extra.c" int main() { foo(); return 0; }
In this way armcc will have visbility over both the declaration (through extra.h included by extra.c) and definition of the function.
I would suggest, for the clarity of the code, to keep the definition and the declaration of the function together in extra.h: this is because the function will be inlined everytime so it does not need to be compiled in a different object file (extra.o).
Hope this helps.
Best Regards,Stefano
Stefano,
Thank you for your thorough and prompt replies. You present another valid but frowned-upon method of keeping the declaration and definition of the function together by including the .c file. I agree that placing the function definition in the header is at least slightly better practice than this. Instead of inlining the function I have instead decided to check a condition outside the function call in the FIQ handler which will never evaluate true unless a fault occurred. In this way, the speed of the function call is less important.