uncalled functions

Hi there!

Yes, they are included. Creating Libraries might be a solution. What I have done lately was just defining an UNUSED compiler constant and doing a

#ifdef UNUSED
// that function you might not need for this version
//...
#endif

Hi Sven,

Thanks for your reply. I've searched the previous threads and it seems like there's some issues regarding the uncalled functions. I guess there's noway to the link would selectively load the functions. I was hoping for some options in the linker that would do this.

Thanks,

Michelle

"I have some uncalled functions and it seems like they are included in the final binary."

This is standard behaviour for any 'C' compiler.
The compiler's job is to turn the source you supply into a corresponding object - not to give a critique of your code!

It is not always possible to determine whether a function is actually called or not; eg, there might be some obscure call via run-time pointers.

You need to either make a Library, or use conditional compilation to remove the unwanted functions.

Libraries are specifically designed to include only those functions actually used in the build.

If it is unreferenced relocatable code (which your routines probably are), they can never be called. (There is no way for your code to figure out where they are. You would have to look up the addresses in the listing, and write another piece of code to use them.) It would be GREAT if the linker had an option to remove unreferenced reloactable code. I can not understand why it is not included. It can not be that hard to implement, and it sure provides a lot of benefits.

"There is no way for your code to figure out where they are."

Yes there is!
The code can use the function's address in a function pointer.

"It can not be that hard to implement"

It is not always possible to determine indirect function calls at link time, so at best it would only be a partial solution.

See App Note 129, and this knowledgebase article:
http://www.keil.com/support/docs/210.htm

NO NO NO!!!

Think about it, how can you get the address into that function pointer? The function is relocatable so you can not hard code it. The only way to obtain it, is to make a reference to it somehow (ie pFn = myFn;). However, as soon as you do that, the compiler has to send the linker a "fixup this address" record ( it is relocatable remember). But it's unreferenced, so there are no such records.

I reiterate, the only way to access unreferenced, relocatable code is to look at the listing, copy the address and write another piece of code to access it.

Assuming you want to allow for the above terrible programming technique, just make it a linker option. If available, I guarantee I will always have it enabled.

Actually there is one bizzare way to call it. That is you first write an assembly routine that has no return! You then instruct the linker to force your relocatable, unreferenced code to follow that assemble routine. This is bizzare code (time to shoot the programmer). I am fine with allowing for this. Just make this removal of unreferenced relocatable dead code a linker option that is by default disabled. It still will be an option I would always use.

Actually, there is another way.

You can create a program with several functions that are not invoked. This program MIGHT be a boot loader.

Then, you can create another program that includes the public symbols only from the absolute object file of the boot loader. The second program could then call the unused functions in the boot loader.

Refer to the following knowledgebase article for ways you can use the PUBLICSONLY directive to do stuff like this.

http://www.keil.com/support/docs/2385.htm

Jon

Thank Jon for an another argument to add to my case. (I used the BL51 so was unaware of this option.)

You have the ability to automatically remove unused library functions by using the one function per file technique. However to make the a boot loader and have these functions available, the programmer must take extra steps to prevent these functions from disappearing. You could foolishly invoke the "it is not safe in every concivable situation" and not allow this auto removal of unreferenced library functions. Thankfully you did not do this. You actually go the other way and make it even easier to get into this situation, by adding this NOPUBLICS option.

The bottom line is the [auto remove "unreference/reloacatable" functions] linker option, would be no more unsafe the the [auto remove of "unreferenced/one function per file" library functions]. It is a poor argument to say "it is not safe in every concivable situation" for both cases.