mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: LKML <linux-kernel@vger.kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Ingo Molnar <mingo@elte.hu>, "H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	jakub@redhat.com
Subject: GCC 4.x random code generator for x86_64 ?
Date: Mon, 7 Dec 2009 18:50:17 +0100 (CET)	[thread overview]
Message-ID: <alpine.LFD.2.00.0912071707540.3089@localhost.localdomain> (raw)

Can anyone shed some light on the following:

Applying a patch which adds a yet unused "extern int bla(void);" line
to a header file results in something which is beyond me.

The .i files differ as expected in exaclty _one_ line.

--- 1.i	2009-12-07 16:23:35.000000000 +0100
+++ 2.i	2009-12-07 16:23:19.000000000 +0100
@@ -6566,6 +6566,8 @@
 extern int _atomic_dec_and_lock(atomic_t *atomic, spinlock_t *lock);
 # 252 "/home/tglx/work/kernel/rt-new/linux-2.6-tip/include/linux/spinlock.h"
 # 1 "/home/tglx/work/kernel/rt-new/linux-2.6-tip/include/linux/rwlock.h" 1
+# 17 "/home/tglx/work/kernel/rt-new/linux-2.6-tip/include/linux/rwlock.h"
+extern int bla(void);
 # 253 "/home/tglx/work/kernel/rt-new/linux-2.6-tip/include/linux/spinlock.h" 2
 
One would expect that the generated code would be the same, but the
resulting code has following surprising deltas (removed the "offset:"
prefix to see the meat of the changes):

 	41 57                	push   %r15
 	41 56                	push   %r14
 	41 55                	push   %r13
+	4c 8d ad 30 ff ff ff 	lea    -0xd0(%rbp),%r13
 	41 54                	push   %r12
 	49 89 fc             	mov    %rdi,%r12
 	53                   	push   %rbx
....
 	48 85 c0             	test   %rax,%rax
 	49 89 c5             	mov    %rax,%r13
-	75 0c                	jne    85 <timecompare_offset+0x52>
-	bb 0a 00 00 00       	mov    $0xa,%ebx
+	75 0c                	jne    8c <timecompare_offset+0x59>
 	4c 8d ad 30 ff ff ff 	lea    -0xd0(%rbp),%r13
+	bb 0a 00 00 00       	mov    $0xa,%ebx
 	45 31 ff             	xor    %r15d,%r15d
 	45 31 f6             	xor    %r14d,%r14d
....
 	44 89 f3             	mov    %r14d,%ebx
 	4c 89 e9             	mov    %r13,%rcx
-	31 d2                	xor    %edx,%edx
 	31 c0                	xor    %eax,%eax
-	eb 09                	jmp    18f <timecompare_offset+0x15c>
+	31 d2                	xor    %edx,%edx
+	eb 09                	jmp    196 <timecompare_offset+0x163>
 	48 03 01             	add    (%rcx),%rax
 	ff c2                	inc    %edx
 	48 83 c1 10          	add    $0x10,%rcx

None of these changes makes any sense at all.

This is fully reproducible and the effect on the generated code
depends on the placement of the "extern int bla(void);" line in the
header file.

Note, I disabled BUG and printk and there is no code which might have
a __LINE__ reference which would be affected by the insertion of that
function declaration.

For enhanced fun the problem goes away, when I compile the same kernel
for 32bit with the very same GCC.

Looks to me that GCC has a builtin random code generator for
x86_64. I'd just like to know whether this can be turned off or if
there is some magic way to seed the RCG reliably.

Environment:
F11 x86_64 
gcc (GCC) 4.4.1 20090725 (Red Hat 4.4.1-2)

The effect is reproducible with the patch below on top of Linus tree
and just compiling kernel/time/timecompare.o

Also verified that other 4.x versions of GCC have similar
randomization effects just in different source files.

Peter just provided:

@@ -62837,8 +62837,8 @@
    3558a:      53                      push   %rbx
    3558b:      e8 00 00 00 00          callq  35590 <cleanup_srcu_struct+0x10>
    35590:      4c 8b 35 00 00 00 00    mov    0x0(%rip),%r14
-   35597:      83 c9 ff                or     $0xffffffffffffffff,%ecx
-   3559a:      45 31 ed                xor    %r13d,%r13d
+   35597:      45 31 ed                xor    %r13d,%r13d
+   3559a:      83 c9 ff                or     $0xffffffffffffffff,%ecx
    3559d:      49 89 fc                mov    %rdi,%r12
    355a0:      eb 14                   jmp    355b6 <cleanup_srcu_struct+0x36>

Thanks,

	tglx
---
 include/linux/spinlock.h |    2 ++
 1 file changed, 2 insertions(+)

Index: linux-2.6-tip/include/linux/spinlock.h
===================================================================
--- linux-2.6-tip.orig/include/linux/spinlock.h
+++ linux-2.6-tip/include/linux/spinlock.h
@@ -57,6 +57,8 @@
 
 #include <asm/system.h>
 
+extern int bla(void);
+
 /*
  * Must define these before including other files, inline functions need them
  */

             reply	other threads:[~2009-12-07 17:50 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-07 17:50 Thomas Gleixner [this message]
2009-12-07 18:13 ` Jakub Jelinek
2009-12-07 23:09   ` Thomas Gleixner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.2.00.0912071707540.3089@localhost.localdomain \
    --to=tglx@linutronix.de \
    --cc=hpa@zytor.com \
    --cc=jakub@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®