> 
> With the GCC 4.2.1 which was working 100% with 6.3.2a.  Except for symlinks, 
> the binutils and gcc look pretty solid.
> 
>  I loaded up the T2 M6 and now binaries with static linkage (-static) error 
> with:
> 
>   LD        platform/bin/symbols/embed
> libc.so: undefined reference to `_mcount_'
> 
> I'll be darned if I can find mcount defined anywhere.  
> 
> NOTE: I am not compiled for gprof.  I don't want gprof in my non-gprof 
> binaries.
> 
> The static libc in M6 definitely has no _mcount_:
> mcount.o:
>          U _mcount_
> 00000000 T mcount
> 

Yep it's missing. And the reason is how it's declared in profile.h

    131 static void __attribute__ ((unused))  _mcount_  __P((uintfptr_t frompc, uintfptr_t selfpc));

The function should be declared with the used attribute so gcc 4.2 still emits the function. Since it's marked with 
unused it only disables the warning but gcc removes it because it is declared static and has no references within the 
translation unit. 6.3.2a, the libc was built with 2.95.3 which didn't optimize as aggressively.

The next milestone should contain _mcount_ but in the meantime you can make the change to the profile.h headers and 
rebuild libc.

Regards,

Ryan Mansfield

Ryan,

Thanks for the excellent reply.  That explains it.  And that 4.2.1 is *good*.  The 2.95 emitted code looks like my hand 
asm code (Jethro-dumb).  The 4.2.1 register coloring/allocation, conditional load/store, branch-delay avoidance are like
 nothing I could ever hand asm code.

However, we are really not a source customer.  If we build source, it is under CM control (as opposed to install 
control).  Tweaking files not under CM is not in our plan.  We *like* having libc be a "binary".  :-)

I wanted to just use the M5 libc (pro-tem) but I am somewhat concerned because the M5 drop appears to have the same 
issue.  Perhaps it is too early for binary customers to migrate to 6.4.

Thanks again for your support.

dave