Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp485284ybg; Fri, 18 Oct 2019 02:54:48 -0700 (PDT) X-Google-Smtp-Source: APXvYqwE2bgYnIZshzAMH2kzhw9ihgbdhdNBIzxDiglPYhUMoNEEQ/J8EUDdRutF3KBfHg3NgBT0 X-Received: by 2002:a17:906:6847:: with SMTP id a7mr7804135ejs.261.1571392488817; Fri, 18 Oct 2019 02:54:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571392488; cv=none; d=google.com; s=arc-20160816; b=G/ub8of76RYey/fTfrxhdHblQfzUKM/OEWeR/XmJ17tkzDSjpV3uEuSmEiCfMLc5gQ HYhDmKnnCcAxwXZrp2BUZvm7APk0TYTTnYn9NIzrx+djz18OGdDsLcxxxFmPoKj4H/BA 9nvQAyWzezH0bUMA4bp5mA0xuiFB3S+szidPhkfEEYhAGKYBBrWgTs9T8FIAx1t+xiZk fYbg7CviH4KbrYPR5H+gJVilM0kxiKB4NW1+qjkyC7yx6s04pEKFMA/wacIO++BLldgT 0fz7gq/nkngf0ckt+JwtQS9V3EOKKyyFZTsKwvKERWI5phwHRukU7DTV/LMe/eMLz8Lv g7Dg== 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=wkICkwl9zBTuUMLsdpAE3rXyU0spND2w2dW2/EB2/oQ=; b=JHT+KDm5NEgBOeItakhyb/rVz574PGrhgMNWJSmVR/E2xK/kNMzHeiy5r7xj0kvo+F 7RCoLHlUaNEBAmFgoGBcAc1yrhMAC3io/Q1KwxuWkWPBmJAc/OvvIt8ZBu9aBBNOdpHy 1C2I0OkszLMEH9nSutzhwsQNaat7iSQkxNZvvF+Rbu7s/a1H+5iGEfhGL84v4lP6NYZ+ 96qtoOs3lBeLuT7HQ7nO39VrmlWwCwQ7BoDUtmuw2TA+b9Z9QKT0hYB1V4zHHDYlzY28 NGJJukWpHc6Xja1HBS1qnttQGuGlJHtbKJVc2OfmJhYKQKa8OJjQ1TZW16tm77xlXXHm zeNg== 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 g20si3023245eje.364.2019.10.18.02.54.25; Fri, 18 Oct 2019 02:54:48 -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 S2404924AbfJQHGY (ORCPT + 99 others); Thu, 17 Oct 2019 03:06:24 -0400 Received: from thoth.sbs.de ([192.35.17.2]:54696 "EHLO thoth.sbs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2390955AbfJQHGX (ORCPT ); Thu, 17 Oct 2019 03:06:23 -0400 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id x9H75TrX028281 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 17 Oct 2019 09:05:29 +0200 Received: from [167.87.38.115] ([167.87.38.115]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id x9H75SUB010204; Thu, 17 Oct 2019 09:05:29 +0200 Subject: Re: [PATCH] scripts/gdb: fix debugging modules on s390 To: Ilya Leoshkevich Cc: Kieran Bingham , linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org, Heiko Carstens , Vasily Gorbik References: <20191015105313.12663-1-iii@linux.ibm.com> <356384d7-d14f-2c9d-1c13-3d96e75e1727@siemens.com> From: Jan Kiszka Message-ID: <5d50b9ad-3e70-27d4-e73a-f67a33b39e7f@siemens.com> Date: Thu, 17 Oct 2019 09:05:28 +0200 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: 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 15.10.19 17:43, Ilya Leoshkevich wrote: >> Am 15.10.2019 um 17:21 schrieb Jan Kiszka : >> >>> @@ -113,6 +113,12 @@ lx-symbols command.""" >>> if module_file: >>> gdb.write("loading @{addr}: {filename}\n".format( >>> addr=module_addr, filename=module_file)) >>> + if utils.is_target_arch('s390'): >>> + # Module text is preceded by PLT stubs on s390. >>> + module_arch = module['arch'] >>> + plt_offset = int(module_arch['plt_offset']) >>> + plt_size = int(module_arch['plt_size']) >>> + module_addr = hex(int(module_addr, 0) + plt_offset + plt_size) >> >> Shouldn't we report the actual address above, ie. reorder this tuning >> with the gdb.write? > > That's a tough question. I thought about this, and the argument for > showing the fixed up address is that if someone does the math with > symbol offsets from e.g. objdump, the result will be consistent with > what gdb shows. > > On the other hand side, why would anyone do this? that's exactly what > this gdb script is for. So showing the actual address at which the > memory was allocated gives the user some additional information, and is > also consistent with what cat /proc/modules would show. > > At the end of the day, I don't have a strong opinion on this, so if you > think it's better to show the fixed up address, I'll send a v2. One of the original ideas of the printout was to provide the information needed to reproduce potential issues manually. From that perspective, the fixed-up address would the the thing to print. If you think the vanilla address has some value as well, we could make an s390-specifi printout of both values. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux