From patchwork Sun Jan 24 08:21:04 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 60272 Delivered-To: patch@linaro.org Received: by 10.112.130.2 with SMTP id oa2csp769116lbb; Sun, 24 Jan 2016 00:21:56 -0800 (PST) X-Received: by 10.66.218.103 with SMTP id pf7mr16962101pac.140.1453623716425; Sun, 24 Jan 2016 00:21:56 -0800 (PST) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id wb3si23863806pab.114.2016.01.24.00.21.55; Sun, 24 Jan 2016 00:21:56 -0800 (PST) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dkim=pass header.i=@linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751282AbcAXIVH (ORCPT + 30 others); Sun, 24 Jan 2016 03:21:07 -0500 Received: from mail-io0-f169.google.com ([209.85.223.169]:34709 "EHLO mail-io0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750861AbcAXIVF (ORCPT ); Sun, 24 Jan 2016 03:21:05 -0500 Received: by mail-io0-f169.google.com with SMTP id 1so125596720ion.1 for ; Sun, 24 Jan 2016 00:21:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PCvkZwBiVozrJTDNzJXZTJi4Ug75iQ9ntjprAqHSQks=; b=NuxHkeEj7t5Jyrq1HazeMLx8xbtYRe77IGYnu3E8ShBX0eKmZUyo7RDcWVzVSFhv4W euUZm9OPIBwFJ9UnrSOkbzodiwpxN0bdLaEv0t6+dJf6HNQaTjgo9l+aIwxvheC8ivNQ l2Pch+fvDS1x+D8FRDgvoOE970CUDP9KCOCOE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PCvkZwBiVozrJTDNzJXZTJi4Ug75iQ9ntjprAqHSQks=; b=Szld97AQ77rdKVlG+UPV+fhQBz2P3wXKlIT9rNobW0LciThpw8vwDiK+Yar/EFGo/P zB3TBC5xF6qJmPjrjiIrMjwA+S/e+/QnXP1jQ543xVh2EqB/YeoqXiwwpk97o86ZDRiz rsSSk9aCwvVHL+rU29wVvZnNYxzvFL/rmqF0/oBdV0XP5TWlsGQcEGjsHfWGgr5c68Dn RadvO1qYfJ3G+CheDkq+GQx9V6lO3KroCjN79gcnFSvbESFWltSTCiavvaNPaILNfcik IfrkMv8x3OBa462KMlEUknK8SwQRJBxfVECcvE2SkZzlM7LDFw/bNPC2RQfCqj2UN344 xjng== X-Gm-Message-State: AG10YOTavtFqJ0C49fBgCQ8CE0JkLfwhZ5KrwyQU//I7BqmaZAWPjZ7XjYqcPhG8nBzqAEbrFYuzuiTIrLlj8bOJ MIME-Version: 1.0 X-Received: by 10.107.128.37 with SMTP id b37mr10852977iod.183.1453623664069; Sun, 24 Jan 2016 00:21:04 -0800 (PST) Received: by 10.36.29.6 with HTTP; Sun, 24 Jan 2016 00:21:04 -0800 (PST) In-Reply-To: <56A477E1.50509@roeck-us.net> References: <56A431B5.8010505@roeck-us.net> <56A43882.50308@roeck-us.net> <56A477E1.50509@roeck-us.net> Date: Sun, 24 Jan 2016 09:21:04 +0100 Message-ID: Subject: Re: Problems with commit 'kallsyms: add support for relative offsets in kallsyms address table' (in mmotm) From: Ard Biesheuvel To: Guenter Roeck Cc: Heiko Carstens , Michael Ellerman , Kees Cook , Andrew Morton , "linux-kernel@vger.kernel.org" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 24 January 2016 at 08:06, Guenter Roeck wrote: > On 01/23/2016 10:10 PM, Ard Biesheuvel wrote: >> >> >> >>> On 24 jan. 2016, at 03:35, Guenter Roeck wrote: >>> >>>> On 01/23/2016 06:06 PM, Guenter Roeck wrote: >>>> Hi, >>>> >>>> I see runtime problems with the current mmotm branch. All qemu mips >>>> targets >>>> (32 and 64 bit, big and little endian) are stuck in boot after this >>>> commit. >>>> >>>> Bisect points to commit d13682e4d9d2 ("kallsyms: add support for >>>> relative offsets >>>> in kallsyms address table". Disabling CONFIG_KALLSYMS_BASE_RELATIVE >>>> fixes the problem, >>>> ie I can boot the image with qemu. >>>> >>>> Bisect log is attached. >>>> >>>> Playing with the problem, I found the following: >>>> >>>> 1) The problem is only seen with a toolchain using binutils 2.22, but >>>> not >>>> with a toolchain using binutils 2.25. The compiler configuration may >>>> be >>>> different for both toolchains. >>>> 2) Message "kallsyms failure: absolute symbol value 0xffffffff807afd14 >>>> out of range >>>> in relative mode" (twice) when using the toolchain with binutils >>>> 2.22. >>>> This does not cause the build to fail, though. >>>> 3) kallsyms_sym_address() parameter variable type is "int". In the >>>> calling code, >>>> the variable type used is "unsigned long". That has no impact on the >>>> problem, >>>> though. >>> >>> >>> An additional data point: When using the older toolchain, many symbols in >>> System.map >>> are marked "A". >>> ffffffff80100000 A _text >>> With the more recent toolchain, the same symbols are marked "T". >>> ffffffff80100000 T _text >>> >> >> Thanks for the analysis. It is surprising that the build does not fail >> when this occurs, and the subsequent hangs themselves are probably caused by >> missing kallsyms data. >> > Yes, I wondered why the build doesn't fail. Seems odd. > >> scripts/kallsyms.c ignores all A symbols except _text, which is actually a >> relative symbol by nature so we can simply assume it is relative (i.e., >> override it as T) >> >> Re x86_64 !SMP, any build time errors there as well? Likewise for sparc32? >> > > Yes, same kind of errors for both. For x86_64/nosmp I also get the error > message > when using the Ubuntu native toolchain, so it doesn't seem to be (directly) > related to binutils 2.22 vs. 2.25 for that architecture. > > Runtime behavior is a bit different for the different architectures. > x86_64 dies silently without any console output, mips just hangs, > and sparc32 gets a panic with NULL pointer access. > Of course, with missing kallsyms data all bets are off. > >> >> Thanks again, and sorry for the trouble, > > > No worries. Hope you'll get this sorted out. > OK, there's an additional issue in my latest version: the kallsyms_relative_base value itself is not relocated. If you have more time to burn on this, could you try the following on top? (If not, that is also fine, I will look into it myself on Monday) Thanks, Ard. diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c index 5ab13394dfd9..0f43f0751d47 100644 --- a/scripts/kallsyms.c +++ b/scripts/kallsyms.c @@ -137,8 +137,10 @@ static int read_symbol(FILE *in, struct sym_entry *s) sym++; /* Ignore most absolute/undefined (?) symbols. */ - if (strcmp(sym, "_text") == 0) + if (strcmp(sym, "_text") == 0) { _text = s->addr; + stype = 'T'; + } else if (check_symbol_range(sym, s->addr, text_ranges, ARRAY_SIZE(text_ranges)) == 0) /* nothing to do */; @@ -406,7 +408,7 @@ static void write_src(void) if (base_relative) { output_label("kallsyms_relative_base"); - printf("\tPTR\t%#llx\n", relative_base); + printf("\tPTR\t_text - %#llx\n", _text - relative_base); printf("\n"); }