* [GIT PULL] x86 LTO changes for v3.15
@ 2014-03-31 21:05 H. Peter Anvin
2014-03-31 21:54 ` Linus Torvalds
` (2 more replies)
0 siblings, 3 replies; 20+ messages in thread
From: H. Peter Anvin @ 2014-03-31 21:05 UTC (permalink / raw)
To: Linus Torvalds
Cc: ak, gleb, hpa, hpa, hubicka, linux-kernel, mingo, pbonzini, perex,
peterz, rostedt, rusty, tglx
Hi Linus,
More infrastructure work in preparation for link-time optimization
(LTO). Most of these changes is to make sure symbols accessed from
assembly code are properly marked as visible so the linker doesn't
remove them.
My understanding is that the changes to support LTO are still not
upstream in binutils, but are on the way there. This patchset should
conclude the x86-specific changes, and remaining patches to actually
enable LTO will be fed through the Kbuild tree (other than keeping up
with changes to the x86 code base, of course), although not
necessarily in this merge window.
The following changes since commit b28a960c42fcd9cfc987441fa6d1c1a471f0f9ed:
Linux 3.14-rc2 (2014-02-09 18:15:47 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-asmlinkage-for-linus
for you to fetch changes up to ef178f9238b142cc1020265e176b20d27fd02ba9:
Kbuild, lto: Handle basic LTO in modpost (2014-02-13 20:25:05 -0800)
----------------------------------------------------------------
Andi Kleen (24):
asmlinkage, kvm: Make kvm_rebooting visible
asmlinkage: Make __iowrite32_copy visible
asmlinkage: Make jiffies visible
asmlinkage, pnp: Make variables used from assembler code visible
asmlinkage: Make lockdep_sys_exit asmlinkage
asmlinkage: Make trace_hardirq visible
asmlinkage, mutex: Mark __visible
asmlinkage: Make main_extable_sort_needed visible
asmlinkage: Mark rwsem functions that can be called from assembler asmlinkage
asmlinkage Make __stack_chk_failed and memcmp visible
asmlinkage, x86: Fix 32bit memcpy for LTO
asmlinkage: Make trace_hardirqs_on/off_caller visible
initconst: Fix initconst mistake in dcdbas
initconst, x86: Fix initconst mistake in ts5500 code
x86, lto: Disable LTO for the x86 VDSO
lto: Make asmlinkage __visible
lto, workaround: Add workaround for initcall reordering
lto: Disable LTO for sys_ni
Kbuild, lto, workaround: Don't warn for initcall_reference in modpost
Kbuild, lto: Drop .number postfixes in modpost
Kbuild, lto: add ld-version and ld-ifversion macros
Kbuild, lto: Add a gcc-ld script to let run gcc as ld
Kbuild, lto: Disable LTO for asm-offsets.c
Kbuild, lto: Handle basic LTO in modpost
Joe Mario (1):
lto: Handle LTO common symbols in module loader
arch/x86/kernel/time.c | 2 +-
arch/x86/lib/memcpy_32.c | 6 +++---
arch/x86/platform/ts5500/ts5500.c | 2 +-
arch/x86/vdso/Makefile | 10 +++++++---
drivers/firmware/dcdbas.c | 2 +-
drivers/pnp/pnpbios/bioscalls.c | 9 +++++----
include/linux/init.h | 20 +++++++++++++++++++-
include/linux/io.h | 2 +-
include/linux/linkage.h | 4 ++--
include/linux/lockdep.h | 2 +-
kernel/Makefile | 3 +++
kernel/extable.c | 2 +-
kernel/locking/lockdep.c | 6 +++---
kernel/locking/mutex.c | 10 +++++-----
kernel/locking/rwsem-xadd.c | 4 ++++
kernel/module.c | 4 ++++
kernel/panic.c | 2 +-
kernel/timer.c | 2 +-
kernel/trace/trace_irqsoff.c | 4 ++--
lib/string.c | 2 +-
scripts/Kbuild.include | 9 +++++++++
scripts/Makefile.build | 2 +-
scripts/gcc-ld | 29 +++++++++++++++++++++++++++++
scripts/ld-version.sh | 8 ++++++++
scripts/mod/modpost.c | 25 +++++++++++++++++++++++--
scripts/mod/modpost.h | 2 +-
virt/kvm/kvm_main.c | 2 +-
27 files changed, 138 insertions(+), 37 deletions(-)
diff --git a/arch/x86/kernel/time.c b/arch/x86/kernel/time.c
index 24d3c91..6ec91c0 100644
--- a/arch/x86/kernel/time.c
+++ b/arch/x86/kernel/time.c
@@ -23,7 +23,7 @@
#include <asm/time.h>
#ifdef CONFIG_X86_64
-DEFINE_VVAR(volatile unsigned long, jiffies) = INITIAL_JIFFIES;
+__visible DEFINE_VVAR(volatile unsigned long, jiffies) = INITIAL_JIFFIES;
#endif
unsigned long profile_pc(struct pt_regs *regs)
diff --git a/arch/x86/lib/memcpy_32.c b/arch/x86/lib/memcpy_32.c
index e78761d..a404b4b 100644
--- a/arch/x86/lib/memcpy_32.c
+++ b/arch/x86/lib/memcpy_32.c
@@ -4,7 +4,7 @@
#undef memcpy
#undef memset
-void *memcpy(void *to, const void *from, size_t n)
+__visible void *memcpy(void *to, const void *from, size_t n)
{
#ifdef CONFIG_X86_USE_3DNOW
return __memcpy3d(to, from, n);
@@ -14,13 +14,13 @@ void *memcpy(void *to, const void *from, size_t n)
}
EXPORT_SYMBOL(memcpy);
-void *memset(void *s, int c, size_t count)
+__visible void *memset(void *s, int c, size_t count)
{
return __memset(s, c, count);
}
EXPORT_SYMBOL(memset);
-void *memmove(void *dest, const void *src, size_t n)
+__visible void *memmove(void *dest, const void *src, size_t n)
{
int d0,d1,d2,d3,d4,d5;
char *ret = dest;
diff --git a/arch/x86/platform/ts5500/ts5500.c b/arch/x86/platform/ts5500/ts5500.c
index 39febb2..9471b94 100644
--- a/arch/x86/platform/ts5500/ts5500.c
+++ b/arch/x86/platform/ts5500/ts5500.c
@@ -88,7 +88,7 @@ struct ts5500_sbc {
static const struct {
const char * const string;
const ssize_t offset;
-} ts5500_signatures[] __initdata = {
+} ts5500_signatures[] __initconst = {
{ "TS-5x00 AMD Elan", 0xb14 },
};
diff --git a/arch/x86/vdso/Makefile b/arch/x86/vdso/Makefile
index fd14be1..9206ac7 100644
--- a/arch/x86/vdso/Makefile
+++ b/arch/x86/vdso/Makefile
@@ -2,6 +2,8 @@
# Building vDSO images for x86.
#
+KBUILD_CFLAGS += $(DISABLE_LTO)
+
VDSO64-$(CONFIG_X86_64) := y
VDSOX32-$(CONFIG_X86_X32_ABI) := y
VDSO32-$(CONFIG_X86_32) := y
@@ -35,7 +37,8 @@ export CPPFLAGS_vdso.lds += -P -C
VDSO_LDFLAGS_vdso.lds = -m64 -Wl,-soname=linux-vdso.so.1 \
-Wl,--no-undefined \
- -Wl,-z,max-page-size=4096 -Wl,-z,common-page-size=4096
+ -Wl,-z,max-page-size=4096 -Wl,-z,common-page-size=4096 \
+ $(DISABLE_LTO)
$(obj)/vdso.o: $(src)/vdso.S $(obj)/vdso.so
@@ -127,7 +130,7 @@ vdso32.so-$(VDSO32-y) += sysenter
vdso32-images = $(vdso32.so-y:%=vdso32-%.so)
CPPFLAGS_vdso32.lds = $(CPPFLAGS_vdso.lds)
-VDSO_LDFLAGS_vdso32.lds = -m32 -Wl,-soname=linux-gate.so.1
+VDSO_LDFLAGS_vdso32.lds = -m32 -Wl,-m,elf_i386 -Wl,-soname=linux-gate.so.1
# This makes sure the $(obj) subdirectory exists even though vdso32/
# is not a kbuild sub-make subdirectory.
@@ -181,7 +184,8 @@ quiet_cmd_vdso = VDSO $@
-Wl,-T,$(filter %.lds,$^) $(filter %.o,$^) && \
sh $(srctree)/$(src)/checkundef.sh '$(NM)' '$@'
-VDSO_LDFLAGS = -fPIC -shared $(call cc-ldoption, -Wl$(comma)--hash-style=sysv)
+VDSO_LDFLAGS = -fPIC -shared $(call cc-ldoption, -Wl$(comma)--hash-style=sysv) \
+ $(LTO_CFLAGS)
GCOV_PROFILE := n
#
diff --git a/drivers/firmware/dcdbas.c b/drivers/firmware/dcdbas.c
index 1b5e8e4..7160c43 100644
--- a/drivers/firmware/dcdbas.c
+++ b/drivers/firmware/dcdbas.c
@@ -584,7 +584,7 @@ static struct platform_driver dcdbas_driver = {
.remove = dcdbas_remove,
};
-static const struct platform_device_info dcdbas_dev_info __initdata = {
+static const struct platform_device_info dcdbas_dev_info __initconst = {
.name = DRIVER_NAME,
.id = -1,
.dma_mask = DMA_BIT_MASK(32),
diff --git a/drivers/pnp/pnpbios/bioscalls.c b/drivers/pnp/pnpbios/bioscalls.c
index 769d265..deb7f4b 100644
--- a/drivers/pnp/pnpbios/bioscalls.c
+++ b/drivers/pnp/pnpbios/bioscalls.c
@@ -21,7 +21,7 @@
#include "pnpbios.h"
-static struct {
+__visible struct {
u16 offset;
u16 segment;
} pnp_bios_callpoint;
@@ -41,6 +41,7 @@ asmlinkage void pnp_bios_callfunc(void);
__asm__(".text \n"
__ALIGN_STR "\n"
+ ".globl pnp_bios_callfunc\n"
"pnp_bios_callfunc:\n"
" pushl %edx \n"
" pushl %ecx \n"
@@ -66,9 +67,9 @@ static struct desc_struct bad_bios_desc = GDT_ENTRY_INIT(0x4092,
* after PnP BIOS oopses.
*/
-u32 pnp_bios_fault_esp;
-u32 pnp_bios_fault_eip;
-u32 pnp_bios_is_utter_crap = 0;
+__visible u32 pnp_bios_fault_esp;
+__visible u32 pnp_bios_fault_eip;
+__visible u32 pnp_bios_is_utter_crap = 0;
static spinlock_t pnp_bios_lock;
diff --git a/include/linux/init.h b/include/linux/init.h
index e168880..a3ba270 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -163,6 +163,23 @@ extern bool initcall_debug;
#ifndef __ASSEMBLY__
+#ifdef CONFIG_LTO
+/* Work around a LTO gcc problem: when there is no reference to a variable
+ * in a module it will be moved to the end of the program. This causes
+ * reordering of initcalls which the kernel does not like.
+ * Add a dummy reference function to avoid this. The function is
+ * deleted by the linker.
+ */
+#define LTO_REFERENCE_INITCALL(x) \
+ ; /* yes this is needed */ \
+ static __used __exit void *reference_##x(void) \
+ { \
+ return &x; \
+ }
+#else
+#define LTO_REFERENCE_INITCALL(x)
+#endif
+
/* initcalls are now grouped by functionality into separate
* subsections. Ordering inside the subsections is determined
* by link order.
@@ -175,7 +192,8 @@ extern bool initcall_debug;
#define __define_initcall(fn, id) \
static initcall_t __initcall_##fn##id __used \
- __attribute__((__section__(".initcall" #id ".init"))) = fn
+ __attribute__((__section__(".initcall" #id ".init"))) = fn; \
+ LTO_REFERENCE_INITCALL(__initcall_##fn##id)
/*
* Early initcalls run before initializing SMP.
diff --git a/include/linux/io.h b/include/linux/io.h
index f4f42fa..8a18e75 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -24,7 +24,7 @@
struct device;
-void __iowrite32_copy(void __iomem *to, const void *from, size_t count);
+__visible void __iowrite32_copy(void __iomem *to, const void *from, size_t count);
void __iowrite64_copy(void __iomem *to, const void *from, size_t count);
#ifdef CONFIG_MMU
diff --git a/include/linux/linkage.h b/include/linux/linkage.h
index a6a42dd..34a513a 100644
--- a/include/linux/linkage.h
+++ b/include/linux/linkage.h
@@ -12,9 +12,9 @@
#endif
#ifdef __cplusplus
-#define CPP_ASMLINKAGE extern "C"
+#define CPP_ASMLINKAGE extern "C" __visible
#else
-#define CPP_ASMLINKAGE
+#define CPP_ASMLINKAGE __visible
#endif
#ifndef asmlinkage
diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index 92b1bfc..7df9aa6 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -265,7 +265,7 @@ extern void lockdep_info(void);
extern void lockdep_reset(void);
extern void lockdep_reset_lock(struct lockdep_map *lock);
extern void lockdep_free_key_range(void *start, unsigned long size);
-extern void lockdep_sys_exit(void);
+extern asmlinkage void lockdep_sys_exit(void);
extern void lockdep_off(void);
extern void lockdep_on(void);
diff --git a/kernel/Makefile b/kernel/Makefile
index bc010ee..31c26c6 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -18,6 +18,9 @@ CFLAGS_REMOVE_cgroup-debug.o = -pg
CFLAGS_REMOVE_irq_work.o = -pg
endif
+# cond_syscall is currently not LTO compatible
+CFLAGS_sys_ni.o = $(DISABLE_LTO)
+
obj-y += sched/
obj-y += locking/
obj-y += power/
diff --git a/kernel/extable.c b/kernel/extable.c
index 763faf0..d8a6446 100644
--- a/kernel/extable.c
+++ b/kernel/extable.c
@@ -36,7 +36,7 @@ extern struct exception_table_entry __start___ex_table[];
extern struct exception_table_entry __stop___ex_table[];
/* Cleared by build time tools if the table is already sorted. */
-u32 __initdata main_extable_sort_needed = 1;
+u32 __initdata __visible main_extable_sort_needed = 1;
/* Sort the kernel's built-in exception table */
void __init sort_main_extable(void)
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index eb8a547..aa3bf15 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -2557,7 +2557,7 @@ static void __trace_hardirqs_on_caller(unsigned long ip)
debug_atomic_inc(hardirqs_on_events);
}
-void trace_hardirqs_on_caller(unsigned long ip)
+__visible void trace_hardirqs_on_caller(unsigned long ip)
{
time_hardirqs_on(CALLER_ADDR0, ip);
@@ -2610,7 +2610,7 @@ EXPORT_SYMBOL(trace_hardirqs_on);
/*
* Hardirqs were disabled:
*/
-void trace_hardirqs_off_caller(unsigned long ip)
+__visible void trace_hardirqs_off_caller(unsigned long ip)
{
struct task_struct *curr = current;
@@ -4191,7 +4191,7 @@ void debug_show_held_locks(struct task_struct *task)
}
EXPORT_SYMBOL_GPL(debug_show_held_locks);
-void lockdep_sys_exit(void)
+asmlinkage void lockdep_sys_exit(void)
{
struct task_struct *curr = current;
diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
index 4dd6e4c..adbc0d0 100644
--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -67,8 +67,7 @@ EXPORT_SYMBOL(__mutex_init);
* We also put the fastpath first in the kernel image, to make sure the
* branch is predicted by the CPU as default-untaken.
*/
-static __used noinline void __sched
-__mutex_lock_slowpath(atomic_t *lock_count);
+__visible void __sched __mutex_lock_slowpath(atomic_t *lock_count);
/**
* mutex_lock - acquire the mutex
@@ -225,7 +224,8 @@ static inline int mutex_can_spin_on_owner(struct mutex *lock)
}
#endif
-static __used noinline void __sched __mutex_unlock_slowpath(atomic_t *lock_count);
+__visible __used noinline
+void __sched __mutex_unlock_slowpath(atomic_t *lock_count);
/**
* mutex_unlock - release the mutex
@@ -746,7 +746,7 @@ __mutex_unlock_common_slowpath(atomic_t *lock_count, int nested)
/*
* Release the lock, slowpath:
*/
-static __used noinline void
+__visible void
__mutex_unlock_slowpath(atomic_t *lock_count)
{
__mutex_unlock_common_slowpath(lock_count, 1);
@@ -803,7 +803,7 @@ int __sched mutex_lock_killable(struct mutex *lock)
}
EXPORT_SYMBOL(mutex_lock_killable);
-static __used noinline void __sched
+__visible void __sched
__mutex_lock_slowpath(atomic_t *lock_count)
{
struct mutex *lock = container_of(lock_count, struct mutex, count);
diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c
index 19c5fa9..1d66e08 100644
--- a/kernel/locking/rwsem-xadd.c
+++ b/kernel/locking/rwsem-xadd.c
@@ -143,6 +143,7 @@ __rwsem_do_wake(struct rw_semaphore *sem, enum rwsem_wake_type wake_type)
/*
* wait for the read lock to be granted
*/
+__visible
struct rw_semaphore __sched *rwsem_down_read_failed(struct rw_semaphore *sem)
{
long count, adjustment = -RWSEM_ACTIVE_READ_BIAS;
@@ -190,6 +191,7 @@ struct rw_semaphore __sched *rwsem_down_read_failed(struct rw_semaphore *sem)
/*
* wait until we successfully acquire the write lock
*/
+__visible
struct rw_semaphore __sched *rwsem_down_write_failed(struct rw_semaphore *sem)
{
long count, adjustment = -RWSEM_ACTIVE_WRITE_BIAS;
@@ -252,6 +254,7 @@ struct rw_semaphore __sched *rwsem_down_write_failed(struct rw_semaphore *sem)
* handle waking up a waiter on the semaphore
* - up_read/up_write has decremented the active part of count if we come here
*/
+__visible
struct rw_semaphore *rwsem_wake(struct rw_semaphore *sem)
{
unsigned long flags;
@@ -272,6 +275,7 @@ struct rw_semaphore *rwsem_wake(struct rw_semaphore *sem)
* - caller incremented waiting part of count and discovered it still negative
* - just wake up any readers at the front of the queue
*/
+__visible
struct rw_semaphore *rwsem_downgrade_wake(struct rw_semaphore *sem)
{
unsigned long flags;
diff --git a/kernel/module.c b/kernel/module.c
index d24fcf2..b99e801 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1948,6 +1948,10 @@ static int simplify_symbols(struct module *mod, const struct load_info *info)
switch (sym[i].st_shndx) {
case SHN_COMMON:
+ /* Ignore common symbols */
+ if (!strncmp(name, "__gnu_lto", 9))
+ break;
+
/* We compiled with -fno-common. These are not
supposed to happen. */
pr_debug("Common symbol: %s\n", name);
diff --git a/kernel/panic.c b/kernel/panic.c
index 6d63003..3eb0ffb 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -459,7 +459,7 @@ EXPORT_SYMBOL(warn_slowpath_null);
* Called when gcc's -fstack-protector feature is used, and
* gcc detects corruption of the on-stack canary value
*/
-void __stack_chk_fail(void)
+__visible void __stack_chk_fail(void)
{
panic("stack-protector: Kernel stack is corrupted in: %p\n",
__builtin_return_address(0));
diff --git a/kernel/timer.c b/kernel/timer.c
index accfd24..d78de04 100644
--- a/kernel/timer.c
+++ b/kernel/timer.c
@@ -52,7 +52,7 @@
#define CREATE_TRACE_POINTS
#include <trace/events/timer.h>
-u64 jiffies_64 __cacheline_aligned_in_smp = INITIAL_JIFFIES;
+__visible u64 jiffies_64 __cacheline_aligned_in_smp = INITIAL_JIFFIES;
EXPORT_SYMBOL(jiffies_64);
diff --git a/kernel/trace/trace_irqsoff.c b/kernel/trace/trace_irqsoff.c
index 2aefbee..887ef88 100644
--- a/kernel/trace/trace_irqsoff.c
+++ b/kernel/trace/trace_irqsoff.c
@@ -498,14 +498,14 @@ void trace_hardirqs_off(void)
}
EXPORT_SYMBOL(trace_hardirqs_off);
-void trace_hardirqs_on_caller(unsigned long caller_addr)
+__visible void trace_hardirqs_on_caller(unsigned long caller_addr)
{
if (!preempt_trace() && irq_trace())
stop_critical_timing(CALLER_ADDR0, caller_addr);
}
EXPORT_SYMBOL(trace_hardirqs_on_caller);
-void trace_hardirqs_off_caller(unsigned long caller_addr)
+__visible void trace_hardirqs_off_caller(unsigned long caller_addr)
{
if (!preempt_trace() && irq_trace())
start_critical_timing(CALLER_ADDR0, caller_addr);
diff --git a/lib/string.c b/lib/string.c
index e5878de..9b1f906 100644
--- a/lib/string.c
+++ b/lib/string.c
@@ -648,7 +648,7 @@ EXPORT_SYMBOL(memmove);
* @count: The size of the area.
*/
#undef memcmp
-int memcmp(const void *cs, const void *ct, size_t count)
+__visible int memcmp(const void *cs, const void *ct, size_t count)
{
const unsigned char *su1, *su2;
int res = 0;
diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
index 547e15d..93a0da2 100644
--- a/scripts/Kbuild.include
+++ b/scripts/Kbuild.include
@@ -155,6 +155,15 @@ ld-option = $(call try-run,\
# Important: no spaces around options
ar-option = $(call try-run, $(AR) rc$(1) "$$TMP",$(1),$(2))
+# ld-version
+# Usage: $(call ld-version)
+# Note this is mainly for HJ Lu's 3 number binutil versions
+ld-version = $(shell $(LD) --version | $(srctree)/scripts/ld-version.sh)
+
+# ld-ifversion
+# Usage: $(call ld-ifversion, -ge, 22252, y)
+ld-ifversion = $(shell [ $(call ld-version) $(1) $(2) ] && echo $(3))
+
######
###
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index d5d859c..9f0ee22 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -198,7 +198,7 @@ $(multi-objs-y:.o=.s) : modname = $(modname-multi)
$(multi-objs-y:.o=.lst) : modname = $(modname-multi)
quiet_cmd_cc_s_c = CC $(quiet_modtag) $@
-cmd_cc_s_c = $(CC) $(c_flags) -fverbose-asm -S -o $@ $<
+cmd_cc_s_c = $(CC) $(c_flags) $(DISABLE_LTO) -fverbose-asm -S -o $@ $<
$(obj)/%.s: $(src)/%.c FORCE
$(call if_changed_dep,cc_s_c)
diff --git a/scripts/gcc-ld b/scripts/gcc-ld
new file mode 100644
index 0000000..cadab9a
--- /dev/null
+++ b/scripts/gcc-ld
@@ -0,0 +1,29 @@
+#!/bin/sh
+# run gcc with ld options
+# used as a wrapper to execute link time optimizations
+# yes virginia, this is not pretty
+
+ARGS="-nostdlib"
+
+while [ "$1" != "" ] ; do
+ case "$1" in
+ -save-temps|-m32|-m64) N="$1" ;;
+ -r) N="$1" ;;
+ -[Wg]*) N="$1" ;;
+ -[olv]|-[Ofd]*|-nostdlib) N="$1" ;;
+ --end-group|--start-group)
+ N="-Wl,$1" ;;
+ -[RTFGhIezcbyYu]*|\
+--script|--defsym|-init|-Map|--oformat|-rpath|\
+-rpath-link|--sort-section|--section-start|-Tbss|-Tdata|-Ttext|\
+--version-script|--dynamic-list|--version-exports-symbol|--wrap|-m)
+ A="$1" ; shift ; N="-Wl,$A,$1" ;;
+ -[m]*) N="$1" ;;
+ -*) N="-Wl,$1" ;;
+ *) N="$1" ;;
+ esac
+ ARGS="$ARGS $N"
+ shift
+done
+
+exec $CC $ARGS
diff --git a/scripts/ld-version.sh b/scripts/ld-version.sh
new file mode 100755
index 0000000..198580d
--- /dev/null
+++ b/scripts/ld-version.sh
@@ -0,0 +1,8 @@
+#!/usr/bin/awk -f
+# extract linker version number from stdin and turn into single number
+ {
+ gsub(".*)", "");
+ split($1,a, ".");
+ print a[1]*10000000 + a[2]*100000 + a[3]*10000 + a[4]*100 + a[5];
+ exit
+ }
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 4061098..63804a1 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -623,7 +623,10 @@ static void handle_modversions(struct module *mod, struct elf_info *info,
switch (sym->st_shndx) {
case SHN_COMMON:
- warn("\"%s\" [%s] is COMMON symbol\n", symname, mod->name);
+ if (!strncmp(symname, "__gnu_lto_", sizeof("__gnu_lto_")-1)) {
+ /* Should warn here, but modpost runs before the linker */
+ } else
+ warn("\"%s\" [%s] is COMMON symbol\n", symname, mod->name);
break;
case SHN_UNDEF:
/* undefined symbol */
@@ -849,6 +852,7 @@ static const char *section_white_list[] =
".xt.lit", /* xtensa */
".arcextmap*", /* arc */
".gnu.linkonce.arcext*", /* arc : modules */
+ ".gnu.lto*",
NULL
};
@@ -1455,6 +1459,10 @@ static void check_section_mismatch(const char *modname, struct elf_info *elf,
to = find_elf_symbol(elf, r->r_addend, sym);
tosym = sym_name(elf, to);
+ if (!strncmp(fromsym, "reference___initcall",
+ sizeof("reference___initcall")-1))
+ return;
+
/* check whitelist - we may ignore it */
if (secref_whitelist(mismatch,
fromsec, fromsym, tosec, tosym)) {
@@ -1680,6 +1688,19 @@ static void check_sec_ref(struct module *mod, const char *modname,
}
}
+static char *remove_dot(char *s)
+{
+ char *end;
+ int n = strcspn(s, ".");
+
+ if (n > 0 && s[n] != 0) {
+ strtoul(s + n + 1, &end, 10);
+ if (end > s + n + 1 && (*end == '.' || *end == 0))
+ s[n] = 0;
+ }
+ return s;
+}
+
static void read_symbols(char *modname)
{
const char *symname;
@@ -1718,7 +1739,7 @@ static void read_symbols(char *modname)
}
for (sym = info.symtab_start; sym < info.symtab_stop; sym++) {
- symname = info.strtab + sym->st_name;
+ symname = remove_dot(info.strtab + sym->st_name);
handle_modversions(mod, &info, sym, symname);
handle_moddevtable(mod, &info, sym, symname);
diff --git a/scripts/mod/modpost.h b/scripts/mod/modpost.h
index 51207e4..168b43d 100644
--- a/scripts/mod/modpost.h
+++ b/scripts/mod/modpost.h
@@ -127,7 +127,7 @@ struct elf_info {
Elf_Section export_gpl_sec;
Elf_Section export_unused_gpl_sec;
Elf_Section export_gpl_future_sec;
- const char *strtab;
+ char *strtab;
char *modinfo;
unsigned int modinfo_len;
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 03a0381..b5ec7fb 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -102,7 +102,7 @@ static void kvm_release_pfn_dirty(pfn_t pfn);
static void mark_page_dirty_in_slot(struct kvm *kvm,
struct kvm_memory_slot *memslot, gfn_t gfn);
-bool kvm_rebooting;
+__visible bool kvm_rebooting;
EXPORT_SYMBOL_GPL(kvm_rebooting);
static bool largepages_enabled = true;
^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [GIT PULL] x86 LTO changes for v3.15
2014-03-31 21:05 [GIT PULL] x86 LTO changes for v3.15 H. Peter Anvin
@ 2014-03-31 21:54 ` Linus Torvalds
2014-03-31 23:03 ` Andi Kleen
2014-04-01 20:49 ` Paul Bolle
2014-04-16 8:53 ` Viresh Kumar
2 siblings, 1 reply; 20+ messages in thread
From: Linus Torvalds @ 2014-03-31 21:54 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Andi Kleen, Gleb Natapov, Peter Anvin, hubicka,
Linux Kernel Mailing List, Ingo Molnar, Paolo Bonzini,
Jaroslav Kysela, Peter Zijlstra, Steven Rostedt, Rusty Russell,
Thomas Gleixner
On Mon, Mar 31, 2014 at 2:05 PM, H. Peter Anvin <hpa@linux.intel.com> wrote:
> diff --git a/include/linux/linkage.h b/include/linux/linkage.h
> index a6a42dd..34a513a 100644
> --- a/include/linux/linkage.h
> +++ b/include/linux/linkage.h
> @@ -12,9 +12,9 @@
> #endif
>
> #ifdef __cplusplus
> -#define CPP_ASMLINKAGE extern "C"
> +#define CPP_ASMLINKAGE extern "C" __visible
> #else
> -#define CPP_ASMLINKAGE
> +#define CPP_ASMLINKAGE __visible
> #endif
This seems to result in new warnings, and they appear to be valid.
We have things like
arch/x86/crypto/sha1_ssse3_glue.c:43:1: warning:
‘externally_visible’ attribute have effect only on public objects
[-Wattributes]
static asmlinkage void (*sha1_transform_asm)(u32 *, const char *,
unsigned int);
^
and it seems to be because "asmlinkage" now means "visible", which is
utter BS. "asmlinkage" is about the calling convention, and visibility
is about something completely different.
So the compiler is actually correct in warning about insane code.
You're basically saying "static" + "visible", which makes no sense.
But "static" + "asmlinkage void (*)" makes sense, because it's about
the "void (*)" being a function with asmlinkage calling convention.
So I think that adding "visible" to asmlinkage is actively wrong and
misguided. And the compiler even told you so, but somebody then chose
to ignore the compiler telling them that they did stupid things.
Don't do crap like this.
Linus
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [GIT PULL] x86 LTO changes for v3.15
2014-03-31 21:54 ` Linus Torvalds
@ 2014-03-31 23:03 ` Andi Kleen
2014-04-01 0:17 ` Linus Torvalds
0 siblings, 1 reply; 20+ messages in thread
From: Andi Kleen @ 2014-03-31 23:03 UTC (permalink / raw)
To: Linus Torvalds
Cc: H. Peter Anvin, Gleb Natapov, Peter Anvin, hubicka,
Linux Kernel Mailing List, Ingo Molnar, Paolo Bonzini,
Jaroslav Kysela, Peter Zijlstra, Steven Rostedt, Rusty Russell,
Thomas Gleixner
> So I think that adding "visible" to asmlinkage is actively wrong and
> misguided. And the compiler even told you so, but somebody then chose
> to ignore the compiler telling them that they did stupid things.
Hi Linus,
In principle you're right. asmlinkage does not mean visible today.
However with LTO pretty much all asmlinkages have to become
visible, as they are used by assembler code and we need to
tell that to the compiler, otherwise it'll optimize it away.
So I abused asmlinkage for this.
The alternative would be to add __visible everywhere we
have asmlinkage today. I thought it was the lesser evil
to just add it implicitly.
If you prefer to do it explicitely I can send
patches (it would be a very mechanic, long and boring
tree sweep ...).
I can send patches for the warnings. Usually the code
throwing warnings for this has some issue anyways,
or the asmlinkage is not really needed.
Please let me know what you prefer.
-Andi
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [GIT PULL] x86 LTO changes for v3.15
2014-03-31 23:03 ` Andi Kleen
@ 2014-04-01 0:17 ` Linus Torvalds
2014-04-01 0:33 ` Linus Torvalds
2014-04-01 1:09 ` Andi Kleen
0 siblings, 2 replies; 20+ messages in thread
From: Linus Torvalds @ 2014-04-01 0:17 UTC (permalink / raw)
To: Andi Kleen
Cc: H. Peter Anvin, Gleb Natapov, Peter Anvin, hubicka,
Linux Kernel Mailing List, Ingo Molnar, Paolo Bonzini,
Jaroslav Kysela, Peter Zijlstra, Steven Rostedt, Rusty Russell,
Thomas Gleixner
On Mon, Mar 31, 2014 at 4:03 PM, Andi Kleen <ak@linux.intel.com> wrote:
>
> However with LTO pretty much all asmlinkages have to become
> visible, as they are used by assembler code and we need to
> tell that to the compiler, otherwise it'll optimize it away.
>
> So I abused asmlinkage for this.
I see why you did it, but I suspect it's not really necessary.
As far as I can tell, *most* of our current asmlinkage use is for the
system call declarations (both compat and regular), and the actual
*definition* of those system calls should pretty much universally use
the SYSCALL_DEFINEx() and COMPAT_SYSCALL_DEFINEx() macros.
So what I would propose is:
- don't do the __visible as part of asmlinkage, because it really is
conceptually wrong
- add the visible to the SYSCALL_DEFINEx() macros
and after that I strongly suspect that there will be only a handful of
cases left that are called from assembly language and that aren't
system calls. Things like "printk()" and friends that are really
special. They'd need a few manual "__visible" annotations.
> If you prefer to do it explicitely I can send
> patches (it would be a very mechanic, long and boring
> tree sweep ...).
See above: I can pretty much guarantee that you should *not* need do
any crazy automated sweeps. Because you shouldn't need "__visible" at
the declarations in the header files, only at the definition of the
function, right? So SYSCALL_DEFINEx() really should catch all the
normal cases.
Linus
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [GIT PULL] x86 LTO changes for v3.15
2014-04-01 0:17 ` Linus Torvalds
@ 2014-04-01 0:33 ` Linus Torvalds
2014-04-01 18:54 ` H. Peter Anvin
2014-04-01 1:09 ` Andi Kleen
1 sibling, 1 reply; 20+ messages in thread
From: Linus Torvalds @ 2014-04-01 0:33 UTC (permalink / raw)
To: Andi Kleen
Cc: H. Peter Anvin, Gleb Natapov, Peter Anvin, Jan Hubicka,
Linux Kernel Mailing List, Ingo Molnar, Paolo Bonzini,
Jaroslav Kysela, Peter Zijlstra, Steven Rostedt, Rusty Russell,
Thomas Gleixner
On Mon, Mar 31, 2014 at 5:17 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> So what I would propose is:
>
> - don't do the __visible as part of asmlinkage, because it really is
> conceptually wrong
>
> - add the visible to the SYSCALL_DEFINEx() macros
>
> and after that I strongly suspect that there will be only a handful of
> cases left that are called from assembly language and that aren't
> system calls. Things like "printk()" and friends that are really
> special. They'd need a few manual "__visible" annotations.
I notice that there seems to be a handful of x86 system calls that
don't use the SYSCALL_DEFINEx() macros to define the system call, some
grepping finds at least ioperm(), modify_ldt(), sigreturn() and
rt_sigreturn(). There are probably others. They should just be
converted to SYSCALL_DEFINEx() while at it. No, x86 doesn't need the
typecasting, but it won't hurt either, and it's good to be consistent.
I'm not sure why those system calls didn't get converted (other
x86-specific ones like vm86() _have_ gotten converted), maybe there's
some reason for it. But I *think* the reason is "nobody noticed".
Linus
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [GIT PULL] x86 LTO changes for v3.15
2014-04-01 0:17 ` Linus Torvalds
2014-04-01 0:33 ` Linus Torvalds
@ 2014-04-01 1:09 ` Andi Kleen
2014-04-01 1:35 ` H. Peter Anvin
2014-04-01 2:26 ` Linus Torvalds
1 sibling, 2 replies; 20+ messages in thread
From: Andi Kleen @ 2014-04-01 1:09 UTC (permalink / raw)
To: Linus Torvalds
Cc: H. Peter Anvin, Gleb Natapov, Peter Anvin, hubicka,
Linux Kernel Mailing List, Ingo Molnar, Paolo Bonzini,
Jaroslav Kysela, Peter Zijlstra, Steven Rostedt, Rusty Russell,
Thomas Gleixner
> - don't do the __visible as part of asmlinkage, because it really is
> conceptually wrong
Ok.
>
> - add the visible to the SYSCALL_DEFINEx() macros
I think SYSCALL_DEFINE actually doesn't need it, as the syscall
tables are visible in C. Only the syscall table itself
needs to be visible.
> and after that I strongly suspect that there will be only a handful of
> cases left that are called from assembly language and that aren't
> system calls. Things like "printk()" and friends that are really
> special. They'd need a few manual "__visible" annotations.
Ok. I think it's more than a handful though.
I'll cook up a patch.
> See above: I can pretty much guarantee that you should *not* need do
> any crazy automated sweeps. Because you shouldn't need "__visible" at
> the declarations in the header files, only at the definition of the
> function, right?
Yes that's right.
-Andi
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [GIT PULL] x86 LTO changes for v3.15
2014-04-01 1:09 ` Andi Kleen
@ 2014-04-01 1:35 ` H. Peter Anvin
2014-04-01 2:26 ` Linus Torvalds
1 sibling, 0 replies; 20+ messages in thread
From: H. Peter Anvin @ 2014-04-01 1:35 UTC (permalink / raw)
To: Andi Kleen, Linus Torvalds
Cc: H. Peter Anvin, Gleb Natapov, hubicka, Linux Kernel Mailing List,
Ingo Molnar, Paolo Bonzini, Jaroslav Kysela, Peter Zijlstra,
Steven Rostedt, Rusty Russell, Thomas Gleixner
On 03/31/2014 06:09 PM, Andi Kleen wrote:
>
> I think SYSCALL_DEFINE actually doesn't need it, as the syscall
> tables are visible in C. Only the syscall table itself
> needs to be visible.
>
I was just going to ask about that. That really means most asmlinkage
instances don't need it at all.
It is also no secret that I wouldn't mind if we could completely get rid
of asmlinkage, but that requires someone to be willing to dig through
all the i386 assembly code.
-hpa
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [GIT PULL] x86 LTO changes for v3.15
2014-04-01 1:09 ` Andi Kleen
2014-04-01 1:35 ` H. Peter Anvin
@ 2014-04-01 2:26 ` Linus Torvalds
1 sibling, 0 replies; 20+ messages in thread
From: Linus Torvalds @ 2014-04-01 2:26 UTC (permalink / raw)
To: Andi Kleen
Cc: H. Peter Anvin, Gleb Natapov, Peter Anvin, Jan Hubicka,
Linux Kernel Mailing List, Ingo Molnar, Paolo Bonzini,
Jaroslav Kysela, Peter Zijlstra, Steven Rostedt, Rusty Russell,
Thomas Gleixner
On Mon, Mar 31, 2014 at 6:09 PM, Andi Kleen <ak@linux.intel.com> wrote:
>
> I think SYSCALL_DEFINE actually doesn't need it, as the syscall
> tables are visible in C. Only the syscall table itself
> needs to be visible.
Ahh, good point. The table used to be in asm for x86-32, but that got
fixed long ago so I guess that just isn't an issue any more.
>> and after that I strongly suspect that there will be only a handful of
>> cases left that are called from assembly language and that aren't
>> system calls. Things like "printk()" and friends that are really
>> special. They'd need a few manual "__visible" annotations.
>
> Ok. I think it's more than a handful though.
I guess an allmodconfig build with the LTO binutils should just
generate linker errors for all of them, so they should be easy to
find, though?
Linus
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [GIT PULL] x86 LTO changes for v3.15
2014-04-01 0:33 ` Linus Torvalds
@ 2014-04-01 18:54 ` H. Peter Anvin
2014-04-01 19:15 ` Linus Torvalds
2014-04-02 0:01 ` Steven Rostedt
0 siblings, 2 replies; 20+ messages in thread
From: H. Peter Anvin @ 2014-04-01 18:54 UTC (permalink / raw)
To: Linus Torvalds, Andi Kleen
Cc: Gleb Natapov, Peter Anvin, Jan Hubicka, Linux Kernel Mailing List,
Ingo Molnar, Paolo Bonzini, Jaroslav Kysela, Peter Zijlstra,
Steven Rostedt, Rusty Russell, Thomas Gleixner
On 03/31/2014 05:33 PM, Linus Torvalds wrote:
>
> I notice that there seems to be a handful of x86 system calls that
> don't use the SYSCALL_DEFINEx() macros to define the system call, some
> grepping finds at least ioperm(), modify_ldt(), sigreturn() and
> rt_sigreturn(). There are probably others. They should just be
> converted to SYSCALL_DEFINEx() while at it. No, x86 doesn't need the
> typecasting, but it won't hurt either, and it's good to be consistent.
>
> I'm not sure why those system calls didn't get converted (other
> x86-specific ones like vm86() _have_ gotten converted), maybe there's
> some reason for it. But I *think* the reason is "nobody noticed".
>
Pretty much. If nothing else, it breaks tracing.
-hpa
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [GIT PULL] x86 LTO changes for v3.15
2014-04-01 18:54 ` H. Peter Anvin
@ 2014-04-01 19:15 ` Linus Torvalds
2014-04-01 19:43 ` H. Peter Anvin
2014-04-02 0:01 ` Steven Rostedt
1 sibling, 1 reply; 20+ messages in thread
From: Linus Torvalds @ 2014-04-01 19:15 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Andi Kleen, Gleb Natapov, Peter Anvin, Jan Hubicka,
Linux Kernel Mailing List, Ingo Molnar, Paolo Bonzini,
Jaroslav Kysela, Peter Zijlstra, Steven Rostedt, Rusty Russell,
Thomas Gleixner
On Tue, Apr 1, 2014 at 11:54 AM, H. Peter Anvin <hpa@linux.intel.com> wrote:
>
> Pretty much. If nothing else, it breaks tracing.
Good point. And those [rt_]sigreturn() system calls might actually be
something you want to see in traces.
Although clearly nobody has noticed the lack so far, so nobody must
have cared all _that_ deeply about them so far ;)
Linus
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [GIT PULL] x86 LTO changes for v3.15
2014-04-01 19:15 ` Linus Torvalds
@ 2014-04-01 19:43 ` H. Peter Anvin
0 siblings, 0 replies; 20+ messages in thread
From: H. Peter Anvin @ 2014-04-01 19:43 UTC (permalink / raw)
To: Linus Torvalds, H. Peter Anvin
Cc: Andi Kleen, Gleb Natapov, Jan Hubicka, Linux Kernel Mailing List,
Ingo Molnar, Paolo Bonzini, Jaroslav Kysela, Peter Zijlstra,
Steven Rostedt, Rusty Russell, Thomas Gleixner
Should be an easy fix through.
On April 1, 2014 12:15:05 PM PDT, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>On Tue, Apr 1, 2014 at 11:54 AM, H. Peter Anvin <hpa@linux.intel.com>
>wrote:
>>
>> Pretty much. If nothing else, it breaks tracing.
>
>Good point. And those [rt_]sigreturn() system calls might actually be
>something you want to see in traces.
>
>Although clearly nobody has noticed the lack so far, so nobody must
>have cared all _that_ deeply about them so far ;)
>
> Linus
--
Sent from my mobile phone. Please pardon brevity and lack of formatting.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [GIT PULL] x86 LTO changes for v3.15
2014-03-31 21:05 [GIT PULL] x86 LTO changes for v3.15 H. Peter Anvin
2014-03-31 21:54 ` Linus Torvalds
@ 2014-04-01 20:49 ` Paul Bolle
2014-04-01 23:17 ` Andi Kleen
2014-04-16 8:53 ` Viresh Kumar
2 siblings, 1 reply; 20+ messages in thread
From: Paul Bolle @ 2014-04-01 20:49 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Linus Torvalds, ak, gleb, hpa, hubicka, linux-kernel, mingo,
pbonzini, perex, peterz, rostedt, rusty, tglx
On Mon, 2014-03-31 at 14:05 -0700, H. Peter Anvin wrote:
> --- a/include/linux/init.h
> +++ b/include/linux/init.h
> @@ -163,6 +163,23 @@ extern bool initcall_debug;
>
> #ifndef __ASSEMBLY__
>
> +#ifdef CONFIG_LTO
I can't find a Kconfig symbol LTO nor a preprocessor define for
CONFIG_LTO. (I only checked master of Linus's tree and linux-next.)
Why is this check for CONFIG_LTO needed?
> +/* Work around a LTO gcc problem: when there is no reference to a variable
> + * in a module it will be moved to the end of the program. This causes
> + * reordering of initcalls which the kernel does not like.
> + * Add a dummy reference function to avoid this. The function is
> + * deleted by the linker.
> + */
> +#define LTO_REFERENCE_INITCALL(x) \
> + ; /* yes this is needed */ \
> + static __used __exit void *reference_##x(void) \
> + { \
> + return &x; \
> + }
> +#else
> +#define LTO_REFERENCE_INITCALL(x)
> +#endif
Paul Bolle
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [GIT PULL] x86 LTO changes for v3.15
2014-04-01 20:49 ` Paul Bolle
@ 2014-04-01 23:17 ` Andi Kleen
2014-04-02 8:29 ` Paul Bolle
0 siblings, 1 reply; 20+ messages in thread
From: Andi Kleen @ 2014-04-01 23:17 UTC (permalink / raw)
To: Paul Bolle
Cc: H. Peter Anvin, Linus Torvalds, gleb, hpa, hubicka, linux-kernel,
mingo, pbonzini, perex, peterz, rostedt, rusty, tglx
On Tue, Apr 01, 2014 at 10:49:51PM +0200, Paul Bolle wrote:
> On Mon, 2014-03-31 at 14:05 -0700, H. Peter Anvin wrote:
> > --- a/include/linux/init.h
> > +++ b/include/linux/init.h
> > @@ -163,6 +163,23 @@ extern bool initcall_debug;
> >
> > #ifndef __ASSEMBLY__
> >
> > +#ifdef CONFIG_LTO
>
> I can't find a Kconfig symbol LTO nor a preprocessor define for
> CONFIG_LTO. (I only checked master of Linus's tree and linux-next.)
The patch for LTO is not merged yet, this is all preparation.
>
> Why is this check for CONFIG_LTO needed?
The comment just below describes the problem.
Or is your question what LTO is? Link Time Optimization
>
> > +/* Work around a LTO gcc problem: when there is no reference to a variable
> > + * in a module it will be moved to the end of the program. This causes
> > + * reordering of initcalls which the kernel does not like.
> > + * Add a dummy reference function to avoid this. The function is
> > + * deleted by the linker.
> > + */
> > +#define LTO_REFERENCE_INITCALL(x) \
> > + ; /* yes this is needed */ \
> > + static __used __exit void *reference_##x(void) \
> > + { \
> > + return &x; \
> > + }
> > +#else
> > +#define LTO_REFERENCE_INITCALL(x)
> > +#endif
--
ak@linux.intel.com -- Speaking for myself only
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [GIT PULL] x86 LTO changes for v3.15
2014-04-01 18:54 ` H. Peter Anvin
2014-04-01 19:15 ` Linus Torvalds
@ 2014-04-02 0:01 ` Steven Rostedt
2014-04-02 0:35 ` Linus Torvalds
1 sibling, 1 reply; 20+ messages in thread
From: Steven Rostedt @ 2014-04-02 0:01 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Linus Torvalds, Andi Kleen, Gleb Natapov, Peter Anvin,
Jan Hubicka, Linux Kernel Mailing List, Ingo Molnar,
Paolo Bonzini, Jaroslav Kysela, Peter Zijlstra, Rusty Russell,
Thomas Gleixner
On Tue, 01 Apr 2014 11:54:23 -0700
"H. Peter Anvin" <hpa@linux.intel.com> wrote:
> On 03/31/2014 05:33 PM, Linus Torvalds wrote:
> >
> > I notice that there seems to be a handful of x86 system calls that
> > don't use the SYSCALL_DEFINEx() macros to define the system call, some
> > grepping finds at least ioperm(), modify_ldt(), sigreturn() and
> > rt_sigreturn(). There are probably others. They should just be
> > converted to SYSCALL_DEFINEx() while at it. No, x86 doesn't need the
> > typecasting, but it won't hurt either, and it's good to be consistent.
> >
> > I'm not sure why those system calls didn't get converted (other
> > x86-specific ones like vm86() _have_ gotten converted), maybe there's
> > some reason for it. But I *think* the reason is "nobody noticed".
> >
>
> Pretty much. If nothing else, it breaks tracing.
Why would they break tracing? I remember there was a issue with compat
calls, are these related to that?
-- Steve
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [GIT PULL] x86 LTO changes for v3.15
2014-04-02 0:01 ` Steven Rostedt
@ 2014-04-02 0:35 ` Linus Torvalds
2014-04-02 12:33 ` Steven Rostedt
0 siblings, 1 reply; 20+ messages in thread
From: Linus Torvalds @ 2014-04-02 0:35 UTC (permalink / raw)
To: Steven Rostedt
Cc: H. Peter Anvin, Andi Kleen, Gleb Natapov, Peter Anvin,
Jan Hubicka, Linux Kernel Mailing List, Ingo Molnar,
Paolo Bonzini, Jaroslav Kysela, Peter Zijlstra, Rusty Russell,
Thomas Gleixner
On Tue, Apr 1, 2014 at 5:01 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> Why would they break tracing? I remember there was a issue with compat
> calls, are these related to that?
They "break" tracing by being invisible to syscall tracing. As you
really should know ;)
The syscall tracing feature depends on the wrappers that
SYSCALL_DEFINEx() creates. See the SYSCALL_TRACE_ENTER_EVENT() etc
crud in <linux/syscalls.h>
So there's no SYSCALL_METADATA for those system calls that weren't
created with the proper SYSCALL_DEFINE() wrappers.
Linus
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [GIT PULL] x86 LTO changes for v3.15
2014-04-01 23:17 ` Andi Kleen
@ 2014-04-02 8:29 ` Paul Bolle
0 siblings, 0 replies; 20+ messages in thread
From: Paul Bolle @ 2014-04-02 8:29 UTC (permalink / raw)
To: Andi Kleen
Cc: H. Peter Anvin, Linus Torvalds, gleb, hpa, hubicka, linux-kernel,
mingo, pbonzini, perex, peterz, rostedt, rusty, tglx
On Tue, 2014-04-01 at 16:17 -0700, Andi Kleen wrote:
> On Tue, Apr 01, 2014 at 10:49:51PM +0200, Paul Bolle wrote:
> > I can't find a Kconfig symbol LTO nor a preprocessor define for
> > CONFIG_LTO. (I only checked master of Linus's tree and linux-next.)
>
> The patch for LTO is not merged yet, this is all preparation.
>
> >
> > Why is this check for CONFIG_LTO needed?
>
> The comment just below describes the problem.
>
> Or is your question what LTO is? Link Time Optimization
I asked the wrong question, as I wanted to ask whether a Kconfig symbol
LTO is perhaps pending somewhere. You basically answered that question
already.
Thanks,
Paul Bolle
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [GIT PULL] x86 LTO changes for v3.15
2014-04-02 0:35 ` Linus Torvalds
@ 2014-04-02 12:33 ` Steven Rostedt
2014-04-02 17:10 ` H. Peter Anvin
0 siblings, 1 reply; 20+ messages in thread
From: Steven Rostedt @ 2014-04-02 12:33 UTC (permalink / raw)
To: Linus Torvalds
Cc: H. Peter Anvin, Andi Kleen, Gleb Natapov, Peter Anvin,
Jan Hubicka, Linux Kernel Mailing List, Ingo Molnar,
Paolo Bonzini, Jaroslav Kysela, Peter Zijlstra, Rusty Russell,
Thomas Gleixner
On Tue, 1 Apr 2014 17:35:05 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Tue, Apr 1, 2014 at 5:01 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > Why would they break tracing? I remember there was a issue with compat
> > calls, are these related to that?
>
> They "break" tracing by being invisible to syscall tracing. As you
> really should know ;)
>
> The syscall tracing feature depends on the wrappers that
> SYSCALL_DEFINEx() creates. See the SYSCALL_TRACE_ENTER_EVENT() etc
> crud in <linux/syscalls.h>
>
> So there's no SYSCALL_METADATA for those system calls that weren't
> created with the proper SYSCALL_DEFINE() wrappers.
>
Heh, I know that not having the SYSCALL_DEFINEx() wrappers means that
they wont be traced. I must have misunderstood Peter, as I thought he
meant if we added SYSCALL_DEFINEx(), that they would break tracing.
IIRC, the compat calls had some issues with the SYSCALL_DEFINE()
macros, and I was thinking theses functions would have some off the
wall issue as well.
Yeah, adding the SYSCALL_DEFINEx() macros around those functions would
be good for tracing as well.
Glad I understand you two now ;-)
I would have thought my jet lag would be over by now.
-- Steve
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [GIT PULL] x86 LTO changes for v3.15
2014-04-02 12:33 ` Steven Rostedt
@ 2014-04-02 17:10 ` H. Peter Anvin
2014-04-02 17:59 ` Steven Rostedt
0 siblings, 1 reply; 20+ messages in thread
From: H. Peter Anvin @ 2014-04-02 17:10 UTC (permalink / raw)
To: Steven Rostedt, Linus Torvalds
Cc: Andi Kleen, Gleb Natapov, Peter Anvin, Jan Hubicka,
Linux Kernel Mailing List, Ingo Molnar, Paolo Bonzini,
Jaroslav Kysela, Peter Zijlstra, Rusty Russell, Thomas Gleixner
On 04/02/2014 05:33 AM, Steven Rostedt wrote:
> On Tue, 1 Apr 2014 17:35:05 -0700
>
> Heh, I know that not having the SYSCALL_DEFINEx() wrappers means that
> they wont be traced. I must have misunderstood Peter, as I thought he
> meant if we added SYSCALL_DEFINEx(), that they would break tracing.
>
No, I meant that them being missing breaks tracing.
>
> Yeah, adding the SYSCALL_DEFINEx() macros around those functions would
> be good for tracing as well.
>
> Glad I understand you two now ;-)
>
:)
Do you want to do the patch?
-hpa
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [GIT PULL] x86 LTO changes for v3.15
2014-04-02 17:10 ` H. Peter Anvin
@ 2014-04-02 17:59 ` Steven Rostedt
0 siblings, 0 replies; 20+ messages in thread
From: Steven Rostedt @ 2014-04-02 17:59 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Linus Torvalds, Andi Kleen, Gleb Natapov, Peter Anvin,
Jan Hubicka, Linux Kernel Mailing List, Ingo Molnar,
Paolo Bonzini, Jaroslav Kysela, Peter Zijlstra, Rusty Russell,
Thomas Gleixner
On Wed, 02 Apr 2014 10:10:12 -0700
"H. Peter Anvin" <hpa@linux.intel.com> wrote:
)
>
> Do you want to do the patch?
Sure, I could probably whip something up.
-- Steve
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [GIT PULL] x86 LTO changes for v3.15
2014-03-31 21:05 [GIT PULL] x86 LTO changes for v3.15 H. Peter Anvin
2014-03-31 21:54 ` Linus Torvalds
2014-04-01 20:49 ` Paul Bolle
@ 2014-04-16 8:53 ` Viresh Kumar
2 siblings, 0 replies; 20+ messages in thread
From: Viresh Kumar @ 2014-04-16 8:53 UTC (permalink / raw)
To: H. Peter Anvin, ak
Cc: Linus Torvalds, gleb, hpa, hubicka, linux-kernel@vger.kernel.org,
Ingo Molnar, pbonzini, perex, Peter Zijlstra, Steven Rostedt,
Rusty Russell, Thomas Gleixner
On Tue, Apr 1, 2014 at 2:35 AM, H. Peter Anvin <hpa@linux.intel.com> wrote:
> Andi Kleen (24):
> Kbuild, lto: Drop .number postfixes in modpost
This generates a new warning with x86_64_defconfig atleast:
scripts/mod/modpost.c: In function 'remove_dot':
scripts/mod/modpost.c:1710:3: warning: ignoring return value of
'strtoul', declared with attribute warn_unused_result
[-Wunused-result]
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2014-04-16 8:53 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-03-31 21:05 [GIT PULL] x86 LTO changes for v3.15 H. Peter Anvin
2014-03-31 21:54 ` Linus Torvalds
2014-03-31 23:03 ` Andi Kleen
2014-04-01 0:17 ` Linus Torvalds
2014-04-01 0:33 ` Linus Torvalds
2014-04-01 18:54 ` H. Peter Anvin
2014-04-01 19:15 ` Linus Torvalds
2014-04-01 19:43 ` H. Peter Anvin
2014-04-02 0:01 ` Steven Rostedt
2014-04-02 0:35 ` Linus Torvalds
2014-04-02 12:33 ` Steven Rostedt
2014-04-02 17:10 ` H. Peter Anvin
2014-04-02 17:59 ` Steven Rostedt
2014-04-01 1:09 ` Andi Kleen
2014-04-01 1:35 ` H. Peter Anvin
2014-04-01 2:26 ` Linus Torvalds
2014-04-01 20:49 ` Paul Bolle
2014-04-01 23:17 ` Andi Kleen
2014-04-02 8:29 ` Paul Bolle
2014-04-16 8:53 ` Viresh Kumar
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox