<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/tools/objtool/arch, branch v4.9.136</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.9.136</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.9.136'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2018-06-05T08:28:58+00:00</updated>
<entry>
<title>objtool: header file sync-up</title>
<updated>2018-06-05T08:28:58+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2018-06-03T10:35:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=269e5906328a6606c893caa8451ecd5b672b0733'/>
<id>urn:sha1:269e5906328a6606c893caa8451ecd5b672b0733</id>
<content type='text'>
When building tools/objtool/ it rightly complains about a number of
files being out of sync.  Fix this up by syncing them properly with the
relevant in-kernel versions.

Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>objtool: sync up with the 4.14.47 version of objtool</title>
<updated>2018-06-05T08:28:57+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2018-06-03T10:35:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b790b4f22a165e85f0b53a3231764034e42c7ea6'/>
<id>urn:sha1:b790b4f22a165e85f0b53a3231764034e42c7ea6</id>
<content type='text'>
There are pros and cons of dealing with tools in the kernel directory.
The pros are the fact that development happens fast, and new features
can be added to the kernel and the tools at the same times.  The cons
are when dealing with backported kernel patches, it can be necessary to
backport parts of the tool changes as well.

For 4.9.y so far, we have backported individual patches.  That quickly
breaks down when there are minor differences between how backports were
handled, so grabbing 40+ patch long series can be difficult, not
impossible, but really frustrating to attempt.

To help mitigate this mess, here's a single big patch to sync up the
objtool logic to the 4.14.47 version of the tool.  From this point
forward (after some other minor header file patches are applied), the
tool should be in sync and much easier to maintain over time.

This has survivied my limited testing, and as the codebase is identical
to 4.14.47, I'm pretty comfortable dropping this big change in here in
4.9.y.  Hopefully all goes well...

Cc: Josh Poimboeuf &lt;jpoimboe@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>objtool: Improve detection of BUG() and other dead ends</title>
<updated>2018-06-05T08:28:55+00:00</updated>
<author>
<name>Josh Poimboeuf</name>
<email>jpoimboe@redhat.com</email>
</author>
<published>2017-02-21T21:35:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=add0ff1791c6a3867329f14a003b7177ce5fd878'/>
<id>urn:sha1:add0ff1791c6a3867329f14a003b7177ce5fd878</id>
<content type='text'>
commit d1091c7fa3d52ebce4dd3f15d04155b3469b2f90 upstream.

The BUG() macro's use of __builtin_unreachable() via the unreachable()
macro tells gcc that the instruction is a dead end, and that it's safe
to assume the current code path will not execute past the previous
instruction.

On x86, the BUG() macro is implemented with the 'ud2' instruction.  When
objtool's branch analysis sees that instruction, it knows the current
code path has come to a dead end.

Peter Zijlstra has been working on a patch to change the WARN macros to
use 'ud2'.  That patch will break objtool's assumption that 'ud2' is
always a dead end.

Generally it's best for objtool to avoid making those kinds of
assumptions anyway.  The more ignorant it is of kernel code internals,
the better.

So create a more generic way for objtool to detect dead ends by adding
an annotation to the unreachable() macro.  The annotation stores a
pointer to the end of the unreachable code path in an '__unreachable'
section.  Objtool can read that section to find the dead ends.

Tested-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Signed-off-by: Josh Poimboeuf &lt;jpoimboe@redhat.com&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Link: http://lkml.kernel.org/r/41a6d33971462ebd944a1c60ad4bf5be86c17b77.1487712920.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>sync objtool's copy of x86-opcode-map.txt</title>
<updated>2018-01-02T19:35:06+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2017-12-31T13:13:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3d16a1315add12386894e7dc7bc86454e4f4b79d'/>
<id>urn:sha1:3d16a1315add12386894e7dc7bc86454e4f4b79d</id>
<content type='text'>
When building objtool, we get the warning:
	warning: objtool: x86 instruction decoder differs from kernel

That's due to commit 2816c0455cea088f07a210f8a00701a82a78aa9c which was
commit 12a78d43de767eaf8fb272facb7a7b6f2dc6a9df upstream that modified
arch/x86/lib/x86-opcode-map.txt without also updating the objtool copy.
The objtool copy was updated in a much larger patch upstream, but we
don't need all of that here, so just update the single file.

If this gets too annoying, I'll just end up doing what we did for 4.14
and backport the whole series to keep this from happening again, but as
this seems to be rare in the 4.9-stable series, this single patch should
be fine.

Cc: Masami Hiramatsu &lt;mhiramat@kernel.org&gt;
Cc: H. Peter Anvin &lt;hpa@zytor.com&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Ingo Molnar &lt;mingo@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;



</content>
</entry>
<entry>
<title>objtool: Fix IRET's opcode</title>
<updated>2017-07-05T12:40:22+00:00</updated>
<author>
<name>Jiri Slaby</name>
<email>jslaby@suse.cz</email>
</author>
<published>2017-01-18T13:29:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c48a862c47d481838b26f5d6cd5c29e2064339da'/>
<id>urn:sha1:c48a862c47d481838b26f5d6cd5c29e2064339da</id>
<content type='text'>
[ Upstream commit b5b46c4740aed1538544f0fa849c5b76c7823469 ]

The IRET opcode is 0xcf according to the Intel manual and also to objdump of my
vmlinux:

    1ea8:       48 cf                   iretq

Fix the opcode in arch_decode_instruction().

The previous value (0xc5) seems to correspond to LDS.

Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
Acked-by: Josh Poimboeuf &lt;jpoimboe@redhat.com&gt;
Cc: Andy Lutomirski &lt;luto@kernel.org&gt;
Cc: Borislav Petkov &lt;bp@alien8.de&gt;
Cc: Brian Gerst &lt;brgerst@gmail.com&gt;
Cc: Denys Vlasenko &lt;dvlasenk@redhat.com&gt;
Cc: H. Peter Anvin &lt;hpa@zytor.com&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Link: http://lkml.kernel.org/r/20170118132921.19319-1-jslaby@suse.cz
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>objtool: Fix bytes check of lea's rex_prefix</title>
<updated>2016-12-06T08:20:59+00:00</updated>
<author>
<name>Jiri Slaby</name>
<email>jslaby@suse.cz</email>
</author>
<published>2016-12-05T10:55:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=69042bf2001b44e81cd86ab11a4637b9d9a14c5a'/>
<id>urn:sha1:69042bf2001b44e81cd86ab11a4637b9d9a14c5a</id>
<content type='text'>
For the "lea %(rsp), %rbp" case, we check if there is a rex_prefix.
But we check 'bytes' which is insn_byte_t[4] in rex_prefix (insn_field
structure). Therefore, the check is always true.

Instead, check 'nbytes' which is the right one.

Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
Acked-by: Josh Poimboeuf &lt;jpoimboe@redhat.com&gt;
Cc: Andy Lutomirski &lt;luto@kernel.org&gt;
Cc: Borislav Petkov &lt;bp@alien8.de&gt;
Cc: Brian Gerst &lt;brgerst@gmail.com&gt;
Cc: Denys Vlasenko &lt;dvlasenk@redhat.com&gt;
Cc: H. Peter Anvin &lt;hpa@zytor.com&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Link: http://lkml.kernel.org/r/20161205105551.25917-1-jslaby@suse.cz
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
</content>
</entry>
<entry>
<title>objtool: Support '-mtune=atom' stack frame setup instruction</title>
<updated>2016-10-11T08:35:45+00:00</updated>
<author>
<name>Josh Poimboeuf</name>
<email>jpoimboe@redhat.com</email>
</author>
<published>2016-10-10T20:24:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2cc17fda94c5ee8c64c2fdc2ef981fc277e2e958'/>
<id>urn:sha1:2cc17fda94c5ee8c64c2fdc2ef981fc277e2e958</id>
<content type='text'>
Arnd reported that enabling CONFIG_MATOM results in a bunch of objtool
false positive frame pointer warnings:

  arch/x86/events/intel/ds.o: warning: objtool: intel_pmu_pebs_del()+0x43: call without frame pointer save/setup
  security/keys/keyring.o: warning: objtool: keyring_read()+0x59: call without frame pointer save/setup
  kernel/signal.o: warning: objtool: __dequeue_signal()+0xd8: call without frame pointer save/setup
  ...

objtool gets confused by the fact that the '-mtune=atom' GCC option
sometimes uses 'lea (%rsp),%rbp' instead of 'mov %rsp,%rbp'.  The
instructions are effectively the same, but objtool doesn't know about
the 'lea' variant.

Fix the false warnings by adding support for 'lea (%rsp),%rbp' in the
objtool decoder.

Reported-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Josh Poimboeuf &lt;jpoimboe@redhat.com&gt;
Cc: Andy Lutomirski &lt;luto@kernel.org&gt;
Cc: Borislav Petkov &lt;bp@alien8.de&gt;
Cc: Brian Gerst &lt;brgerst@gmail.com&gt;
Cc: Denys Vlasenko &lt;dvlasenk@redhat.com&gt;
Cc: H. Peter Anvin &lt;hpa@zytor.com&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
</content>
</entry>
<entry>
<title>Merge branch 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip</title>
<updated>2016-07-30T18:54:53+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2016-07-30T18:54:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=228ffba23e6865651c12626d5b46524a205ba810'/>
<id>urn:sha1:228ffba23e6865651c12626d5b46524a205ba810</id>
<content type='text'>
Pull misc fixes from Thomas Gleixner:
 "This update contains:

   - a fix for stomp-machine so the nmi_watchdog wont trigger on the cpu
     waiting for the others to execute the callback

   - various fixes and updates to objtool including an resync of the
     instruction decoder to match the kernel's decoder"

* 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  objtool: Un-capitalize "Warning" for out-of-sync instruction decoder
  objtool: Resync x86 instruction decoder with the kernel's
  objtool: Support new GCC 6 switch jump table pattern
  stop_machine: Touch_nmi_watchdog() after MULTI_STOP_PREPARE
  objtool: Add 'fixdep' to objtool/.gitignore
</content>
</entry>
<entry>
<title>objtool: Resync x86 instruction decoder with the kernel's</title>
<updated>2016-07-29T14:57:16+00:00</updated>
<author>
<name>Josh Poimboeuf</name>
<email>jpoimboe@redhat.com</email>
</author>
<published>2016-07-29T00:14:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8d94c2f9198301bd78feb1d9ad6c08a8ee7b5d1c'/>
<id>urn:sha1:8d94c2f9198301bd78feb1d9ad6c08a8ee7b5d1c</id>
<content type='text'>
This fixes the following warning:

  Warning: objtool: x86 instruction decoder differs from kernel

Unfortunately we have three identical copies of the x86 instruction
decoder in the kernel tree that have to be manually kept in sync.

It's on my TODO list to at least library-ize the ones in the tools
subdir so we'd only have two of them instead of three.  In the meantime,
here's another manual sync.

Reported-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Josh Poimboeuf &lt;jpoimboe@redhat.com&gt;
Cc: Andy Lutomirski &lt;luto@kernel.org&gt;
Cc: Borislav Petkov &lt;bp@alien8.de&gt;
Cc: Brian Gerst &lt;brgerst@gmail.com&gt;
Cc: Denys Vlasenko &lt;dvlasenk@redhat.com&gt;
Cc: H. Peter Anvin &lt;hpa@zytor.com&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Fixes: c61f4d5ebaf0 ("perf tools: Add AVX-512 support to the instruction decoder used by Intel PT")
Link: http://lkml.kernel.org/r/d7f74b4d91fed25b0be33cd5c86f5131fa1a7529.1469751119.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
</content>
</entry>
<entry>
<title>x86/insn: remove pcommit</title>
<updated>2016-07-23T18:04:23+00:00</updated>
<author>
<name>Dan Williams</name>
<email>dan.j.williams@intel.com</email>
</author>
<published>2016-06-02T18:06:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fd1d961dd681d58308456049a817cbf4c0662018'/>
<id>urn:sha1:fd1d961dd681d58308456049a817cbf4c0662018</id>
<content type='text'>
The pcommit instruction is being deprecated in favor of either ADR
(asynchronous DRAM refresh: flush-on-power-fail) at the platform level, or
posted-write-queue flush addresses as defined by the ACPI 6.x NFIT (NVDIMM
Firmware Interface Table).

Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: "H. Peter Anvin" &lt;hpa@zytor.com&gt;
Cc: x86@kernel.org
Cc: Josh Poimboeuf &lt;jpoimboe@redhat.com&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Arnaldo Carvalho de Melo &lt;acme@kernel.org&gt;
Cc: Alexander Shishkin &lt;alexander.shishkin@linux.intel.com&gt;
Cc: Borislav Petkov &lt;bp@suse.de&gt;
Cc: Andy Lutomirski &lt;luto@kernel.org&gt;
Cc: Xiao Guangrong &lt;guangrong.xiao@linux.intel.com&gt;
Cc: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: Ross Zwisler &lt;ross.zwisler@linux.intel.com&gt;
Acked-by: Ingo Molnar &lt;mingo@redhat.com&gt;
Signed-off-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
</content>
</entry>
</feed>
