Andi Kleen wrote: > On Thu, Jan 10, 2008 at 04:59:52PM -0800, John Reiser wrote: > >>Andi Kleen wrote: >> >>>But actually checking the default implementation in linkage.h already >>>implements size: [snip] >> >>>Are you sure it doesn't work? Your patch should be not needed. If it's >>>still wrong then just ENDPROCs() need to be added. >> >>The ENDPROCs() were not used everywhere. Some code used just END() instead, >>while other code used nothing. um/sys-i386/checksum.S didn't #include > > > END() is fine too since it contains .size too: > > #ifndef END > #define END(name) \ > .size name, .-name > #endif > > >>diff --git a/arch/x86/lib/semaphore_32.S b/arch/x86/lib/semaphore_32.S >>index 444fba4..e2c6e0d 100644 >>--- a/arch/x86/lib/semaphore_32.S >>+++ b/arch/x86/lib/semaphore_32.S >>@@ -49,7 +49,7 @@ ENTRY(__down_failed) >> ENDFRAME >> ret >> CFI_ENDPROC >>- END(__down_failed) >>+ ENDPROC(__down_failed) > > > I don't think these change makes sense given the definition of END() > shown above. > > The only change that would make sense is adding END() (or ENDPROC()) > to a function that doesn't have either of them yet.
No. The pseudo op ".type name, @function" appears only in ENDPROC; it does not appear in END. So changing END to ENDPROC *does* alter the Elf32_Sym for 'name'. Just END produces STT_NOTYPE; ENDPROC produces STT_FUNC. A static analysis tool can get the info it wants much more easily if all subroutines are marked as STT_FUNC. In theory the tool could sort the symbols, notice the disjoint coverage of the address space by the .size intervals of consecutive symbols that are the targets of a CALL instruction, and thus deduce that ".type foo, @function" *should* have been specified. But this is a heuristic, and it fails on boundaries where assembly code is invoked via trap, interrupt, or exception (anything other than CALL). Instead, specify STT_FUNC for each subroutine in the first place. That requires .type, which means ENDPROC (not END) from linux/linkage.h. -- John Reiser, [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
