Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1730376 > unrolled thread
| Started by | Arnd Bergmann <arnd@arndb.de> |
|---|---|
| First post | 2017-09-11 16:40 +0200 |
| Last post | 2017-09-21 15:30 +0200 |
| Articles | 5 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: gcc-8 objtool warnings Arnd Bergmann <arnd@arndb.de> - 2017-09-11 16:40 +0200
Re: gcc-8 objtool warnings Josh Poimboeuf <jpoimboe@redhat.com> - 2017-09-19 22:00 +0200
Re: gcc-8 objtool warnings Arnd Bergmann <arnd@arndb.de> - 2017-09-19 22:50 +0200
Re: gcc-8 objtool warnings Josh Poimboeuf <jpoimboe@redhat.com> - 2017-09-19 23:40 +0200
Re: gcc-8 objtool warnings Arnd Bergmann <arnd@arndb.de> - 2017-09-21 15:30 +0200
| From | Arnd Bergmann <arnd@arndb.de> |
|---|---|
| Date | 2017-09-11 16:40 +0200 |
| Subject | Re: gcc-8 objtool warnings |
| Message-ID | <uoy2u-4xg-11@gated-at.bofh.it> |
On Thu, Aug 24, 2017 at 9:19 PM, Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> On Thu, Aug 24, 2017 at 12:14:27PM +0200, Arnd Bergmann wrote:
>> On Wed, Aug 23, 2017 at 6:01 PM, Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>> > On Wed, Aug 23, 2017 at 03:38:02PM +0200, Arnd Bergmann wrote:
>> >> On Wed, Aug 23, 2017 at 2:48 PM, Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>> >> > On Wed, Aug 23, 2017 at 02:22:34PM +0200, Arnd Bergmann wrote:
>> >> >> ...
>> >> >>
>> >> >> 0000000000000000 <put_cred_rcu.cold.1>:
>> >> >> 0: e8 00 00 00 00 callq 5 <put_cred_rcu.cold.1+0x5>
>> >> >> 1: R_X86_64_PC32 __sanitizer_cov_trace_pc-0x4
>> >> >> 5: 44 8b 8b 64 ff ff ff mov -0x9c(%rbx),%r9d
>> >> >> c: 48 8b 8b 68 ff ff ff mov -0x98(%rbx),%rcx
>> >> >> 13: 44 89 e2 mov %r12d,%edx
>> >> >> 16: 44 8b 83 60 ff ff ff mov -0xa0(%rbx),%r8d
>> >> >> 1d: 4c 89 ee mov %r13,%rsi
>> >> >> 20: 48 c7 c7 00 00 00 00 mov $0x0,%rdi
>> >> >> 23: R_X86_64_32S .rodata.str1.8+0x28
>> >> >> 27: e8 00 00 00 00 callq 2c <__kstrtab_creds_are_invalid+0x3>
>> >> >> 28: R_X86_64_PC32 panic-0x4
>> >> >
>> >> > Thanks. Can you send me one of the .o files?
>> >>
>> >> Attached here now.
>> >
>> > Ok, looks like I'll need to add support for this new pattern (jumping to
>> > a .cold section in .text.unlikely).
>> >
>> > I'm also about to start work on fixing that other issue you found with
>> > GCC's inefficient update of the stack pointer.
>> >
>> > I really appreciate your finding all these warnings (and getting advance
>> > GCC 8 testing). Thanks again!
>>
>> No worries. I've disabled the four warnings in objtool that triggered now
>> and almost all are gone, but I still get a few warnings after doing additional
>> randconfig builds.
>
> Ok, I've got a fix for *most* of them below.
>
> Still need to fix the gc.o warning, which at first glance looks like a
> new switch statement pattern.
I now got around to testing your patch, and ran into a few remaining
problems:
1. one configuration causing tons of warnings, on most compiler
versions (4.9 and newer), and even a couple of "unreachable
instruction warnings on gcc-4.3.
arch/x86/mm/pageattr.o: warning: objtool: set_memory_x()+0x3a: call
without frame pointer save/setup
security/keys/keyring.o: warning: objtool: keyring_read()+0x70: leave
instruction with modified stack frame
arch/x86/events/intel/pt.o: warning: objtool:
pt_event_addr_filters_sync uses BP as a scratch register
2. one configuration showing two warnings in a file that is compile
with "-O0", reproducible with gcc-4.9 and above (gcc-6 and above show
slightly different results from older versions):
crypto/jitterentropy.o: warning: objtool: jent_stuck()+0xbc: leave
instruction with modified stack frame
crypto/jitterentropy.o: warning: objtool:
jent_entropy_collector_free()+0x64: leave instruction with modified
stack frame
or
crypto/jitterentropy.o: warning: objtool: jent_fold_time()+0x3b: call
without frame pointer save/setup
crypto/jitterentropy.o: warning: objtool: jent_stuck()+0x1d: call
without frame pointer save/setup
crypto/jitterentropy.o: warning: objtool: jent_unbiased_bit()+0x15:
call without frame pointer save/setup
crypto/jitterentropy.o: warning: objtool: jent_read_entropy()+0x32:
call without frame pointer save/setup
crypto/jitterentropy.o: warning: objtool:
jent_entropy_collector_free()+0x19: call without frame pointer
save/setup
3. A few dozen "sibling call from callable instruction with modified
stack frame" warnings in one configuration using gcc-8, e.g.
drivers/infiniband/hw/cxgb4/ev.o: warning: objtool:
c4iw_ev_dispatch()+0xff: sibling call from callable instruction with
modified stack frame
drivers/infiniband/ulp/srpt/ib_srpt.o: warning: objtool:
srpt_rdma_read_done.cold.40()+0xa3: sibling call from callable
instruction with modified stack frame
drivers/isdn/hardware/avm/b1.o: warning: objtool:
b1_parse_version()+0x234: sibling call from callable instruction with
modified stack frame
drivers/isdn/hardware/mISDN/mISDNisar.o: warning: objtool:
isar_fill_fifo()+0x17f: sibling call from callable instruction with
modified stack frame
4. a small number of other warnings in various configurations, also using gcc-8:
fs/btrfs/extent_io.o: warning: objtool: __clear_extent_bit() falls
through to next function endio_readpage_release_extent()
drivers/mtd/nand/nand_base.o: warning: objtool:
nand_scan_tail()+0x25f: sibling call from callable instruction with
modified stack frame
fs/fat/inode.o: warning: objtool: parse_options()+0x26c: unreachable instruction
drivers/media/tuners/tuner-simple.o: warning: objtool:
simple_set_params.cold.20()+0x0: unreachable instruction
drivers/media/tuners/tda8290.o: warning: objtool:
tda829x_attach.cold.18()+0x0: unreachable instruction
drivers/media/tuners/xc5000.o: warning: objtool:
xc5000_set_digital_params.cold.32()+0xe5: unreachable instruction
drivers/mtd/nand/nand_base.o: warning: objtool:
nand_scan_tail()+0x231: sibling call from callable instruction with
modified stack frame
fs/btrfs/extent_io.o: warning: objtool: __clear_extent_bit() falls
through to next function set_extent_bit()
drivers/edac/mce_amd.o: warning: objtool: f16h_mc2_mce()+0x32: sibling
call from callable instruction with modified stack frame
drivers/gpu/drm/radeon/cik.o: warning: objtool:
cik_init_microcode()+0x4d: sibling call from callable instruction with
modified stack frame
drivers/media/dvb-frontends/drxk_hard.o: warning: objtool:
set_qam.constprop.9()+0x778: sibling call from callable instruction
with modified stack frame
drivers/message/fusion/mptbase.o: warning: objtool:
mpt_HardResetHandler() falls through to next function
mpt_Soft_Hard_ResetHandler()
drivers/message/fusion/mptbase.o: warning: objtool:
mpt_Soft_Hard_ResetHandler() falls through to next function
mptbase_sas_persist_operation()
drivers/video/fbdev/tridentfb.o: warning: objtool:
trident_pci_probe.part.9()+0x1e1: sibling call from callable
instruction with modified stack frame
drivers/message/fusion/mptbase.o: warning: objtool:
mpt_Soft_Hard_ResetHandler() falls through to next function
mptbase_sas_persist_operation()
I've uploaded the relevant files for you to
https://drive.google.com/file/d/0B_XQwQ5KlfJAbUtrTVJaRmJIZUk/view?usp=sharing
Arnd
[toc] | [next] | [standalone]
| From | Josh Poimboeuf <jpoimboe@redhat.com> |
|---|---|
| Date | 2017-09-19 22:00 +0200 |
| Message-ID | <urwQz-1e6-47@gated-at.bofh.it> |
| In reply to | #1730376 |
On Mon, Sep 11, 2017 at 04:34:52PM +0200, Arnd Bergmann wrote: > On Thu, Aug 24, 2017 at 9:19 PM, Josh Poimboeuf <jpoimboe@redhat.com> wrote: > > On Thu, Aug 24, 2017 at 12:14:27PM +0200, Arnd Bergmann wrote: > >> On Wed, Aug 23, 2017 at 6:01 PM, Josh Poimboeuf <jpoimboe@redhat.com> wrote: > >> > On Wed, Aug 23, 2017 at 03:38:02PM +0200, Arnd Bergmann wrote: > >> >> On Wed, Aug 23, 2017 at 2:48 PM, Josh Poimboeuf <jpoimboe@redhat.com> wrote: > >> >> > On Wed, Aug 23, 2017 at 02:22:34PM +0200, Arnd Bergmann wrote: > >> >> >> ... > >> >> >> > >> >> >> 0000000000000000 <put_cred_rcu.cold.1>: > >> >> >> 0: e8 00 00 00 00 callq 5 <put_cred_rcu.cold.1+0x5> > >> >> >> 1: R_X86_64_PC32 __sanitizer_cov_trace_pc-0x4 > >> >> >> 5: 44 8b 8b 64 ff ff ff mov -0x9c(%rbx),%r9d > >> >> >> c: 48 8b 8b 68 ff ff ff mov -0x98(%rbx),%rcx > >> >> >> 13: 44 89 e2 mov %r12d,%edx > >> >> >> 16: 44 8b 83 60 ff ff ff mov -0xa0(%rbx),%r8d > >> >> >> 1d: 4c 89 ee mov %r13,%rsi > >> >> >> 20: 48 c7 c7 00 00 00 00 mov $0x0,%rdi > >> >> >> 23: R_X86_64_32S .rodata.str1.8+0x28 > >> >> >> 27: e8 00 00 00 00 callq 2c <__kstrtab_creds_are_invalid+0x3> > >> >> >> 28: R_X86_64_PC32 panic-0x4 > >> >> > > >> >> > Thanks. Can you send me one of the .o files? > >> >> > >> >> Attached here now. > >> > > >> > Ok, looks like I'll need to add support for this new pattern (jumping to > >> > a .cold section in .text.unlikely). > >> > > >> > I'm also about to start work on fixing that other issue you found with > >> > GCC's inefficient update of the stack pointer. > >> > > >> > I really appreciate your finding all these warnings (and getting advance > >> > GCC 8 testing). Thanks again! > >> > >> No worries. I've disabled the four warnings in objtool that triggered now > >> and almost all are gone, but I still get a few warnings after doing additional > >> randconfig builds. > > > > Ok, I've got a fix for *most* of them below. > > > > Still need to fix the gc.o warning, which at first glance looks like a > > new switch statement pattern. > > I now got around to testing your patch, and ran into a few remaining > problems: > > 1. one configuration causing tons of warnings, on most compiler > versions (4.9 and newer), and even a couple of "unreachable > instruction warnings on gcc-4.3. > > arch/x86/mm/pageattr.o: warning: objtool: set_memory_x()+0x3a: call > without frame pointer save/setup > security/keys/keyring.o: warning: objtool: keyring_read()+0x70: leave > instruction with modified stack frame > arch/x86/events/intel/pt.o: warning: objtool: > pt_event_addr_filters_sync uses BP as a scratch register I downloaded the tarball, and I see configs/logs for the other problems, but not for this one. Did you forget to attach it, or did I miss it? -- Josh
[toc] | [prev] | [next] | [standalone]
| From | Arnd Bergmann <arnd@arndb.de> |
|---|---|
| Date | 2017-09-19 22:50 +0200 |
| Message-ID | <urxCW-1Jf-17@gated-at.bofh.it> |
| In reply to | #1735213 |
On Tue, Sep 19, 2017 at 9:52 PM, Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> On Mon, Sep 11, 2017 at 04:34:52PM +0200, Arnd Bergmann wrote:
>> On Thu, Aug 24, 2017 at 9:19 PM, Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>> 1. one configuration causing tons of warnings, on most compiler
>> versions (4.9 and newer), and even a couple of "unreachable
>> instruction warnings on gcc-4.3.
>>
>> arch/x86/mm/pageattr.o: warning: objtool: set_memory_x()+0x3a: call
>> without frame pointer save/setup
>> security/keys/keyring.o: warning: objtool: keyring_read()+0x70: leave
>> instruction with modified stack frame
>> arch/x86/events/intel/pt.o: warning: objtool:
>> pt_event_addr_filters_sync uses BP as a scratch register
>
> I downloaded the tarball, and I see configs/logs for the other problems,
> but not for this one. Did you forget to attach it, or did I miss it?
I think what I ended up doing was to take the smallest files for that
configuration and packed them up, but the warnings I listed in the
mail don't match the ones for those files. However, it seems the
0xEBFDB964_defconfig/log file got corrupted.
I've uploaded a new copy to http://paste.ubuntu.com/25574959/ now.
I've also experimented with other compiler versions
in the meantime and ran into similar problems on those version but did
not bother to take detailed notes about them since they are likely just
variants of the ones I already reported. If you can work around the
warnings I reported here, I can rerun with all compilers I have to
see if anything else shows up.
Arnd
[toc] | [prev] | [next] | [standalone]
| From | Josh Poimboeuf <jpoimboe@redhat.com> |
|---|---|
| Date | 2017-09-19 23:40 +0200 |
| Message-ID | <urypj-2ht-7@gated-at.bofh.it> |
| In reply to | #1735252 |
On Tue, Sep 19, 2017 at 10:43:31PM +0200, Arnd Bergmann wrote:
> On Tue, Sep 19, 2017 at 9:52 PM, Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> > On Mon, Sep 11, 2017 at 04:34:52PM +0200, Arnd Bergmann wrote:
> >> On Thu, Aug 24, 2017 at 9:19 PM, Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> >> 1. one configuration causing tons of warnings, on most compiler
> >> versions (4.9 and newer), and even a couple of "unreachable
> >> instruction warnings on gcc-4.3.
> >>
> >> arch/x86/mm/pageattr.o: warning: objtool: set_memory_x()+0x3a: call
> >> without frame pointer save/setup
> >> security/keys/keyring.o: warning: objtool: keyring_read()+0x70: leave
> >> instruction with modified stack frame
> >> arch/x86/events/intel/pt.o: warning: objtool:
> >> pt_event_addr_filters_sync uses BP as a scratch register
> >
> > I downloaded the tarball, and I see configs/logs for the other problems,
> > but not for this one. Did you forget to attach it, or did I miss it?
>
> I think what I ended up doing was to take the smallest files for that
> configuration and packed them up, but the warnings I listed in the
> mail don't match the ones for those files. However, it seems the
> 0xEBFDB964_defconfig/log file got corrupted.
>
> I've uploaded a new copy to http://paste.ubuntu.com/25574959/ now.
>
> I've also experimented with other compiler versions
> in the meantime and ran into similar problems on those version but did
> not bother to take detailed notes about them since they are likely just
> variants of the ones I already reported. If you can work around the
> warnings I reported here, I can rerun with all compilers I have to
> see if anything else shows up.
Here's the fix for #1 and #2. I still need to work on the GCC 8
warnings.
-----
From: Josh Poimboeuf <jpoimboe@redhat.com>
Subject: [PATCH] objtool: Support unoptimized frame pointer setup
Arnd Bergmann reported a bunch of warnings like:
crypto/jitterentropy.o: warning: objtool: jent_fold_time()+0x3b: call without frame pointer save/setup
crypto/jitterentropy.o: warning: objtool: jent_stuck()+0x1d: call without frame pointer save/setup
crypto/jitterentropy.o: warning: objtool: jent_unbiased_bit()+0x15: call without frame pointer save/setup
crypto/jitterentropy.o: warning: objtool: jent_read_entropy()+0x32: call without frame pointer save/setup
crypto/jitterentropy.o: warning: objtool: jent_entropy_collector_free()+0x19: call without frame pointer save/setup
and
arch/x86/events/core.o: warning: objtool: collect_events uses BP as a scratch register
arch/x86/events/core.o: warning: objtool: events_ht_sysfs_show()+0x22: call without frame pointer save/setup
With certain rare configurations, GCC sometimes sets up the frame
pointer with:
lea (%rsp),%rbp
instead of:
mov %rsp,%rbp
The instructions are equivalent, so treat the former like the latter.
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
---
tools/objtool/arch/x86/decode.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/tools/objtool/arch/x86/decode.c b/tools/objtool/arch/x86/decode.c
index 0e8c8ec4fd4e..97a1fdb3db63 100644
--- a/tools/objtool/arch/x86/decode.c
+++ b/tools/objtool/arch/x86/decode.c
@@ -284,11 +284,16 @@ int arch_decode_instruction(struct elf *elf, struct section *sec,
case 0x8d:
if (sib == 0x24 && rex_w && !rex_b && !rex_x) {
- /* lea disp(%rsp), reg */
*type = INSN_STACK;
- op->src.type = OP_SRC_ADD;
+ if (!insn.displacement.value) {
+ /* lea (%rsp), reg */
+ op->src.type = OP_SRC_REG;
+ } else {
+ /* lea disp(%rsp), reg */
+ op->src.type = OP_SRC_ADD;
+ op->src.offset = insn.displacement.value;
+ }
op->src.reg = CFI_SP;
- op->src.offset = insn.displacement.value;
op->dest.type = OP_DEST_REG;
op->dest.reg = op_to_cfi_reg[modrm_reg][rex_r];
--
2.13.5
[toc] | [prev] | [next] | [standalone]
| From | Arnd Bergmann <arnd@arndb.de> |
|---|---|
| Date | 2017-09-21 15:30 +0200 |
| Message-ID | <us9Id-1wS-7@gated-at.bofh.it> |
| In reply to | #1735269 |
On Tue, Sep 19, 2017 at 11:39 PM, Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> On Tue, Sep 19, 2017 at 10:43:31PM +0200, Arnd Bergmann wrote:
> -----
> From: Josh Poimboeuf <jpoimboe@redhat.com>
> Subject: [PATCH] objtool: Support unoptimized frame pointer setup
>
> Arnd Bergmann reported a bunch of warnings like:
>
> crypto/jitterentropy.o: warning: objtool: jent_fold_time()+0x3b: call without frame pointer save/setup
> crypto/jitterentropy.o: warning: objtool: jent_stuck()+0x1d: call without frame pointer save/setup
> crypto/jitterentropy.o: warning: objtool: jent_unbiased_bit()+0x15: call without frame pointer save/setup
> crypto/jitterentropy.o: warning: objtool: jent_read_entropy()+0x32: call without frame pointer save/setup
> crypto/jitterentropy.o: warning: objtool: jent_entropy_collector_free()+0x19: call without frame pointer save/setup
>
> and
>
> arch/x86/events/core.o: warning: objtool: collect_events uses BP as a scratch register
> arch/x86/events/core.o: warning: objtool: events_ht_sysfs_show()+0x22: call without frame pointer save/setup
>
> With certain rare configurations, GCC sometimes sets up the frame
> pointer with:
>
> lea (%rsp),%rbp
>
> instead of:
>
> mov %rsp,%rbp
>
> The instructions are equivalent, so treat the former like the latter.
>
> Reported-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Confirmed, this fixes many configurations that had warnings before,
currently testing with gcc-6.3.
Arnd
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web