Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp113317ybx; Wed, 30 Oct 2019 12:10:19 -0700 (PDT) X-Google-Smtp-Source: APXvYqyNVNMJRD0YsWTodlE/dNJpn3jPEwKypDIeu9qdK/NosSHJEmr7jeXDBObJi7dlBRqH3VGV X-Received: by 2002:a50:af44:: with SMTP id g62mr1502245edd.164.1572462619205; Wed, 30 Oct 2019 12:10:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1572462619; cv=none; d=google.com; s=arc-20160816; b=lO4pkOyalGqutwZ9KEUKYsxj7hntpiuQzO9PZSyJHnYZT9A6PavVxarz9nhYTK66sg EVnLwsU68wF+S0U/OCaJse2MU9U58OLEGTj7LXRV0EtJG3mFm4+fjKe1gKzGCDsWRCJt CbLEacxSK94sk0pvZLRwzNcycpTnc0bimZMF6R/rSz6fjQXBnpal11VrhvVprYHbDGvW 20egxDGfo5VfTKbjiqLeekbvJf7NF1Tg9W9tWN2cV4PRJMkdZ7ydey3KntDT468FTmpP aKggNUxAqutvFvU+u0fu9blMxw8mE+7Zw0H4frh5oDPwqlXzxQMMvi9/zRMq6uDbeJ/f t7cA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=5/BRpmsDlGz8okPjY58UF/rimoEMNxXpEqjXyE9Q9Hg=; b=qk4+Mg6v4rsBnjuffFoNcRxM89aBbsTkvPl+xTXo6lEzqstpY+bSGY0V9r7E2jpUU2 WPHYJXCgWCjnNNpz9C8tp3Trpj/ITV2gRZRqX8HMtKJCQ5LBopXr5P+bbIQNC99yAefW RkjqmXzGGTvBXpqWjRaI5FOcJOuGtAz4uJvKXvz8k4EIf1EiekCfaniwOLhK+bjKvBrs EpTb63x2eZ0JcbCYgT0Za8HxyDdtSMtGZ6pCxbEEtr/7J+VNLetrmKNOFiUr9GjxUlO3 dXfRMYVj9InVxcQaarzGjpYosIDgGJWwbIUUrB8xmSs1+qg1K5L/vvoeoAGM9jrkiebO gkXg== ARC-Authentication-Results: i=1; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s20si1859140eju.421.2019.10.30.12.09.55; Wed, 30 Oct 2019 12:10:19 -0700 (PDT) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727411AbfJ3S3w (ORCPT + 99 others); Wed, 30 Oct 2019 14:29:52 -0400 Received: from david.siemens.de ([192.35.17.14]:55175 "EHLO david.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726795AbfJ3S3v (ORCPT ); Wed, 30 Oct 2019 14:29:51 -0400 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id x9UITYZc006975 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 30 Oct 2019 19:29:34 +0100 Received: from [167.87.33.44] ([167.87.33.44]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id x9UITXgO017475; Wed, 30 Oct 2019 19:29:34 +0100 Subject: Re: [PATCH] scripts/gdb: fix debugging modules compiled with hot/cold partitioning To: Ilya Leoshkevich , Kieran Bingham , linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org, Andrew Morton Cc: Heiko Carstens , Vasily Gorbik References: <20191028152734.13065-1-iii@linux.ibm.com> From: Jan Kiszka Message-ID: <130e31f0-ce38-77cb-58a9-cedf3b0f8113@siemens.com> Date: Wed, 30 Oct 2019 19:29:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 MIME-Version: 1.0 In-Reply-To: <20191028152734.13065-1-iii@linux.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 28.10.19 16:27, Ilya Leoshkevich wrote: > gcc's -freorder-blocks-and-partition option makes it group frequently > and infrequently used code in .text.hot and .text.unlikely sections > respectively. At least when building modules on s390, this option is > used by default. > > gdb assumes that all code is located in .text section, and that .text > section is located at module load address. With such modules this is no > longer the case: there is code in .text.hot and .text.unlikely, and > either of them might precede .text. > > Fix by explicitly telling gdb the addresses of code sections. > > It might be tempting to do this for all sections, not only the ones in > the white list. Unfortunately, gdb appears to have an issue, when telling > it about e.g. loadable .note.gnu.build-id section causes it to think that > non-loadable .note.Linux section is loaded at address 0, which in turn > causes NULL pointers to be resolved to bogus symbols. So keep using the > white list approach for the time being. Did you report this to gdb? > > Signed-off-by: Ilya Leoshkevich > --- > scripts/gdb/linux/symbols.py | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/scripts/gdb/linux/symbols.py b/scripts/gdb/linux/symbols.py > index 7b7c2fafbc68..be984aa29b75 100644 > --- a/scripts/gdb/linux/symbols.py > +++ b/scripts/gdb/linux/symbols.py > @@ -99,7 +99,8 @@ lx-symbols command.""" > attrs[n]['name'].string(): attrs[n]['address'] > for n in range(int(sect_attrs['nsections']))} > args = [] > - for section_name in [".data", ".data..read_mostly", ".rodata", ".bss"]: > + for section_name in [".data", ".data..read_mostly", ".rodata", ".bss", > + ".text", ".text.hot", ".text.unlikely"]: > address = section_name_to_address.get(section_name) > if address: > args.append(" -s {name} {addr}".format( > Reviewed-by: Jan Kiszka Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux