From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752592AbdCAJwH (ORCPT ); Wed, 1 Mar 2017 04:52:07 -0500 Received: from mail-oi0-f65.google.com ([209.85.218.65]:35225 "EHLO mail-oi0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751845AbdCAJvd (ORCPT ); Wed, 1 Mar 2017 04:51:33 -0500 MIME-Version: 1.0 In-Reply-To: References: <20161010125709.1870563-1-arnd@arndb.de> <20161011150541.opini6gbolmnpzy5@treble> <20161011155146.icyl3zewdvmms2h2@treble> <2252957.Vm1BYSSRqP@wuerfel> From: Arnd Bergmann Date: Wed, 1 Mar 2017 10:45:03 +0100 X-Google-Sender-Auth: 2k3mA2ECZHE0vducz1RK8DMSF3c Message-ID: Subject: Re: [PATCH] [RFC] x86: avoid -mtune=atom for objtool warnings To: Josh Poimboeuf Cc: Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Linux Kernel Mailing List , Denys Vlasenko Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 1, 2017 at 10:34 AM, Arnd Bergmann wrote: > On Tue, Oct 11, 2016 at 10:38 PM, Arnd Bergmann wrote: >> On Tuesday, October 11, 2016 10:51:46 AM CEST Josh Poimboeuf wrote: >>> >>> 3) 0xFC244C03-config: >>> drivers/scsi/fnic/fnic_main.o: warning: objtool: fnic_log_q_error() falls through to next function fnic_handle_link_event() >>> drivers/scsi/snic/snic_res.o: warning: objtool: .text: unexpected end of section >>> >>> These look like another bad gcc bug which is truncating functions: >> >> Same bug for both of them? > > I ran into this one again today, after updating to the latest gcc-7.0.1: > > drivers/infiniband/sw/rxe/rxe_resp.o: warning: objtool: > rxe_responder()+0xfe: sibling call from callable instruction with > changed frame pointer > > Josh, did you get around to updating objtool the last time I reported it, or > is it still the same problem? If this is a new variation, I can provide more > details about the failure, otherwise I'll just ignore it for now. Actually, something must have changed in gcc since last month, I also just got a report in another file: drivers/i2c/busses/i2c-img-scb.o: warning: objtool: img_i2c_probe() falls through to next function img_i2c_read_fifo() See below for the relevant snippet from the assembler output. Arnd # /git/arm-soc/drivers/i2c/busses/i2c-img-scb.c:1176: if (i2c->bitrate <= timings[i].max_bitrate) { movl 1648(%rbx), %edx # MEM[(struct img_i2c *)_29].bitrate, _99 cmpl timings+8(%rip), %edx # timings[0].max_bitrate, _99 # /git/arm-soc/drivers/i2c/busses/i2c-img-scb.c:1171: i2c->need_wr_rd_fence = true; movb $1, 1652(%rbx) #, MEM[(struct img_i2c *)_29].need_wr_rd_fence movl timings+48(%rip), %ecx # timings[1].max_bitrate, pretmp_260 # /git/arm-soc/drivers/i2c/busses/i2c-img-scb.c:1176: if (i2c->bitrate <= timings[i].max_bitrate) { jbe .L59 #, cmpl %ecx, %edx # pretmp_260, _99 jbe .L60 #, .L61: # /git/arm-soc/drivers/i2c/busses/i2c-img-scb.c:1182: dev_warn(i2c->adap.dev.parent, movq 240(%rbx), %rdi # MEM[(struct img_i2c *)_29].adap.dev.parent, MEM[(struct img_i2c *)_29].adap.dev.parent movq $.LC12, %rsi #, call dev_warn # # /git/arm-soc/drivers/i2c/busses/i2c-img-scb.c:1187: i2c->bitrate = timing.max_bitrate; movl timings+48(%rip), %eax # MEM[(struct img_i2c_timings *)&timings + 48B], MEM[(struct img_i2c_timings *)&timings + 48B] movl %eax, 1648(%rbx) # MEM[(struct img_i2c_timings *)&timings + 48B], MEM[(struct img_i2c *)_29].bitrate .L60: ud2 .L66: # /git/arm-soc/drivers/i2c/busses/i2c-img-scb.c:1360: dev_err(&pdev->dev, "can't request irq %d\n", irq); movl %r13d, %edx # , movq $.LC6, %rsi #, movq %r14, %rdi # _1, call dev_err # # /git/arm-soc/drivers/i2c/busses/i2c-img-scb.c:1361: return ret; movl -52(%rbp), %eax # %sfp, _62 movl %eax, %r13d # _62, jmp .L52 # .L65: # /git/arm-soc/drivers/i2c/busses/i2c-img-scb.c:1341: dev_err(&pdev->dev, "can't get irq number\n"); movq $.LC5, %rsi #, movq %r14, %rdi # _1, call dev_err # # /git/arm-soc/drivers/i2c/busses/i2c-img-scb.c:1342: return irq; jmp .L52 # .L67: # /git/arm-soc/drivers/i2c/busses/i2c-img-scb.c:1162: dev_info(i2c->adap.dev.parent, movzbl %ah, %ecx # ret, tmp150 movq 240(%rbx), %rdi # MEM[(struct img_i2c *)_29].adap.dev.parent, MEM[(struct img_i2c *)_29].adap.dev.parent movl %eax, %edx # ret, tmp153 movl %ecx, %r8d # tmp150, tmp150 movl %eax, %ecx # ret, tmp151 movzbl %al, %r9d # ret, shrl $16, %ecx #, tmp151 shrl $24, %edx #, tmp153 movq $.LC11, %rsi #, movzbl %cl, %ecx # tmp151, tmp152 # /git/arm-soc/drivers/i2c/busses/i2c-img-scb.c:1404: return ret; movl $-22, %r13d #, # /git/arm-soc/drivers/i2c/busses/i2c-img-scb.c:1162: dev_info(i2c->adap.dev.parent, call _dev_info # # /git/arm-soc/include/linux/clk.h:210: might_sleep(); xorl %edx, %edx # movl $210, %esi #, movq $.LC0, %rdi #, call __might_sleep # xorl %edx, %edx # movl $210, %esi #, movq $.LC0, %rdi #, call __might_sleep # # /git/arm-soc/drivers/i2c/busses/i2c-img-scb.c:1404: return ret; jmp .L52 # .L62: # /git/arm-soc/drivers/i2c/busses/i2c-img-scb.c:1332: return -ENOMEM; movl $-12, %r13d #, jmp .L52 # .L59: # /git/arm-soc/drivers/i2c/busses/i2c-img-scb.c:1181: if (i2c->bitrate > timings[ARRAY_SIZE(timings) - 1].max_bitrate) { cmpl %ecx, %edx # pretmp_260, _99 ja .L61 #, ud2 .size img_i2c_probe, .-img_i2c_probe .p2align 4,,15 .type img_i2c_read_fifo, @function img_i2c_read_fifo: 1: call __fentry__ # /git/arm-soc/drivers/i2c/busses/i2c-img-scb.c:545: while (i2c->msg.len) { cmpw $0, 1828(%rdi) #, i2c_10(D)->msg.len # /git/arm-soc/drivers/i2c/busses/i2c-img-scb.c:544: { pushq %rbp # movq %rsp, %rbp #, # /git/arm-soc/drivers/i2c/busses/i2c-img-scb.c:545: while (i2c->msg.len) { je .L68 #, # /git/arm-soc/arch/x86/include/asm/io.h:66: build_mmio_write(writel, "l", unsigned int, "r", :"memory") xorl %esi, %esi # tmp118 movl $255, %ecx #, tmp119 jmp .L71 #