BMC/Intel-BMC/linux.git/arch/tile/lib/memcpy_user_64.c, branch dev

modpost: work correctly with tile coldtext sections

2015-07-08T22:53:49+00:00

The tilegx and tilepro compilers use .coldtext for their unlikely executed text section name, so an __attribute__((cold)) function will (when compiled with higher optimization levels) land in the .coldtext section. Modify modpost to add .coldtext to the set of OTHER_TEXT_SECTIONS so we don't get warnings about referencing such a section in an __ex_table block, and then also modify arch/tile/lib/memcpy_user_64.c so that it uses plain ".coldtext" instead of ".coldtext.memcpy". The latter naming is a relic of an earlier use of -ffunction-sections, which we no longer use by default. Signed-off-by: Chris Metcalf Acked-by: Rusty Russell

tile: use proper .align directives on __ex_table sections

2013-08-30T15:56:11+00:00

This may fix a reported bug where an R_TILEGX_64 in a module was not pointing to an aligned address. Reported-by: Simon Marchi Signed-off-by: Chris Metcalf

arch/tile: make sure to build memcpy_user_64 without frame pointer

2012-04-02T16:12:42+00:00

Add a comment explaining why this is important, and add a CFLAGS_REMOVE clause to the Makefile to make sure it happens. Signed-off-by: Chris Metcalf

arch/tile: finish enabling support for TILE-Gx 64-bit chip

2011-05-12T19:52:12+00:00

This support was partially present in the existing code (look for "__tilegx__" ifdefs) but with this change you can build a working kernel using the TILE-Gx toolchain and ARCH=tilegx. Most of these files are new, generally adding a foo_64.c file where previously there was just a foo_32.c file. The ARCH=tilegx directive redirects to arch/tile, not arch/tilegx, using the existing SRCARCH mechanism in the top-level Makefile. Changes to existing files: - and changed to factor the include of in the common header. - and arch/tile/kernel/compat.c changed to remove the "const" markers I had put on compat_sys_execve() when trying to match some recent similar changes to the non-compat execve. It turns out the compat version wasn't "upgraded" to use const. - and were previously included accidentally, with the 32-bit contents. Now they have the proper 64-bit contents. Finally, I had to hack the existing hacky drivers/input/input-compat.h to add yet another "#ifdef" for INPUT_COMPAT_TEST (same as x86_64). Signed-off-by: Chris Metcalf Acked-by: Dmitry Torokhov [drivers/input]