David Brown wrote on Montag, 19. September 2005 09:53 : > I'm not too hot on the internals of gcc, but I'm wondering if there is not > already a mechanism in place for gcc to detect purely internal linkage (by > which I mean a "static" function whose address is never taken). When a > function is declared "inline", the compiler has to know whether it must > also generate an "outline" version as well - if it knows the function is > "static" and the address is never taken, the "outline" version is not > generated. Could this also be used to determine if a stub is needed or not? > If this were possible, then the stub could be avoided by simply declaring > functions to be "static" if they are not needed externally to the file, > cutting down the overhead substantially, since the majority of functions > can be labelled "static". Of course, that requires a bit of discipline on > the part of the programmer, as they would have to use "static" explicitly > on all non-extern functions. But that's good practice anyway (and easily > checked with "-Wmissing-prototypes" ). Maybe. I however don't know right now how to do that right now. I rather have looked for a *easy to implement and safe* method. For this reason, e.g., I also did not implement the jump stubs as RTL but rather as text. > An alternative idea might be to use individual sections such as > ".text1_foo" for the stub for function foo(), and make use of the > "--gc-sections" option in the linker to remove any such section that is not > used. > I'm thinking of the same idea as the "-ffunction-sections" switch in > gcc which can be used with "--gc-sections" to avoid linking in functions > that are not used. I haven't tried the "-ffunction-sections" switch, and > don't even know if it is implemented for the avr port, but perhaps the same > idea can be used. If the -ffunction-sections is functional, this would probably be the easiest and best approach.
BTW, I just recognized that one probably will also need to disable or modify the table jump insn patterns. Björn _______________________________________________ AVR-libc-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
