Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 13 Feb 2020 17:16:51 -0600
From:   Josh Poimboeuf <jpoimboe@redhat.com>
To:     Fangrui Song <maskray@google.com>
Cc:     Nick Desaulniers <ndesaulniers@google.com>, peterz@infradead.org,
        clang-built-linux@googlegroups.com,
        Nathan Chancellor <natechancellor@gmail.com>,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH] objtool: ignore .L prefixed local symbols
Message-ID: <20200213231651.alogip6tupegsbvq@treble>
References: <20200213184708.205083-1-ndesaulniers@google.com>
 <20200213221758.i6pchz4gsiy2lsyc@treble>
 <20200213223734.3zjrvhshjyr5ca7p@google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20200213223734.3zjrvhshjyr5ca7p@google.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Feb 13, 2020 at 02:37:34PM -0800, Fangrui Song wrote:
> I still consider such a check (tools/objtool/check.c:679) unneeded.
> 
> st_type doesn't have to be STT_FUNC. Either STT_NOTYPE or STT_FUNC is
> ok. If STT_GNU_IFUNC is used, it can be ok as well.
> (My clang patch skips STT_GNU_IFUNC just because rtld typically doesn't
>  cache R_*_IRELATIVE results. Having two STT_GNU_IFUNC symbols with same st_shndx and
>  st_value can create two R_*_IRELATIVE, which need to be resolved twice
>  at runtime.)
> 
> 	} else if (rela->sym->type == STT_SECTION) {
> 		insn->call_dest = find_symbol_by_offset(rela->sym->sec,
> 							rela->addend+4);
> 		if (!insn->call_dest ||
> 		    insn->call_dest->type != STT_FUNC) {
> 			WARN_FUNC("can't find call dest symbol at %s+0x%x",
> 				  insn->sec, insn->offset,
> 				  rela->sym->sec->name,
> 				  rela->addend + 4);
> 			return -1;
> 		}
> 
> 
> 	.section	.init.text,"ax",@progbits
> 	call	printk
> 	call	.Lprintk$local
> 	.text
> 	.globl	printk
> 	.type	printk,@function
> printk:
> .Lprintk$local:
>  ret

Objtool isn't a general ELF validator, it's more of a kernel sanity
validator.  In the kernel we currently have a constraint that you can
only call STT_FUNC.  At the very least it helps keep our asm code clean.

If that constraint ever becomes a problem then we could always
reconsider it.

> % llvm-mc -filetype=obj -triple=riscv64 a.s -mattr=+relax -o a.o
> % readelf -Wr a.o
> 
> Relocation section '.rela.init.text' at offset 0xa0 contains 4 entries:
>     Offset             Info             Type               Symbol's Value  Symbol's Name + Addend
> 0000000000000000  0000000200000012 R_RISCV_CALL           0000000000000000 printk + 0
> 0000000000000000  0000000000000033 R_RISCV_RELAX                             0
> 0000000000000008  0000000100000012 R_RISCV_CALL           0000000000000000 .Lprintk$local + 0
> 0000000000000008  0000000000000033 R_RISCV_RELAX                             0
> 
> 
> On RISC-V, when relaxation is enabled, .L cannot be resolved at assembly
> time because sections can shrink.
> 
> https://sourceware.org/binutils/docs/as/Symbol-Names.html
> 
> > Local symbols are defined and used within the assembler, but they are *normally* not saved in object files.
> 
> I consider the GNU as issue a missed optimization, instead of a bug.
> There is no rigid rule that .L symbols cannot be saved in object files.

I know nothing about RISC-V, but if I understand correctly,
.Lprintk$local is the function's local entry point, similar to ppc64
localentry.  Would it not always be a constant offset from the printk
address, such that the relocation could be "printk + 8" or so?

Regardless, it doesn't really matter for now, objtool is x86-only.

-- 
Josh