• State Not Answered
  • Locked Locked
  • Replies 11 replies
  • Subscribers 22 subscribers
  • Views 1625 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

not used functions linked and declares XDATA for local vars

Sergio Santos

Hello,

I have detected that some functions like this one are using their own XDATA space instead of using the XDATA_GROUP for local purposes:

for example this one:

void zmemcpy2(UINT8 *dst,const UINT8 *src, UINT32 len)
{

      --dst;   --src;
       while (len--)
       {
          *(++dst) = *(++src);
   }
}

then this is the line in the m51 file:

XDATA   82C2H     000AH     UNIT         ?XD?_ZMEMCPY2?LIB


so then Im wasting ten bytes of global data space for just a memcopy. Why is this happening?

And here it is another weird thing: this function is never used by the rest of the program. It is compiled, but should not be linked.
any idea?

thanks in advance...

Parents
  • 0 in reply to Drew Davis

    thank you,

    I will try that REMOVEUNUSED option. I actually thought that it was a default option for any linker, so I am a bit confused about it. I've been reading that I have to use the extended linker lX51 and a very up-to-date version, otherwise that option is unknown.

    About using our own memcopy2, its possible to write more efficient and smaller functions. OK its not an ANSI compliant, but it is a better choice for us.

Reply
  • 0 in reply to Drew Davis

    thank you,

    I will try that REMOVEUNUSED option. I actually thought that it was a default option for any linker, so I am a bit confused about it. I've been reading that I have to use the extended linker lX51 and a very up-to-date version, otherwise that option is unknown.

    About using our own memcopy2, its possible to write more efficient and smaller functions. OK its not an ANSI compliant, but it is a better choice for us.

Children
  • 0 in reply to Sergio Santos

    Most linkers in my experience do remove unused code. This option is a new addition to the Keil toolchain, though.

    (Thanks for putting it in, guys. It certainly made our life easier.)

  • 0 in reply to Drew Davis

    Most linkers in my experience do remove unused code.

    Actually not!

    Some linkers ignores object files that are not referenced.

    A linker is normally not able to know the contents of an object file and to surgically remove functions from it if not used. That is why most runtime libraries contains hundreds or thousands of tiny object files.

    '51 compilers/linkers are a bit special because of the lack of real stack space, where the linker must analyse call chains for allocation of global parameter areas.

  • 0 in reply to Per Westermark

    A Library is a special type of object file specifically designed so that the Linker can pick out only those functions that are actually required;

    Otherwise, in general, if you tell a Linker to include an Object file, it will do so - it's up to you not to tell the Linker to link unused stuff!

  • 0 in reply to Sergio Santos

    Sergio Santos wrote:
    I've been reading that I have to use the extended linker lX51

    This is true. the standard linker doesn't have the REMOVEUNUSED option. If you didn't buy the extended linker you can still use the demo version but it is code size limited.

  • 0 in reply to Andy Neil

    A Library is a special type of object file specifically designed so that the Linker can pick out only those functions that are actually required;

    fully stated: "so that the Linker can pick out only those modules containing functions that are actually required"

    you can easily get 'unused functions' from a library if the modules there contain more than one function.

    Erik