From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id vAShJvmJ+mGvUQAAWB0awg (envelope-from ) for ; Wed, 02 Feb 2022 08:41:13 -0500 Received: by simark.ca (Postfix, from userid 112) id 8CC5E1F3BA; Wed, 2 Feb 2022 08:41:13 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 782151EE1A for ; Wed, 2 Feb 2022 08:41:07 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9BB42385C411 for ; Wed, 2 Feb 2022 13:41:06 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9BB42385C411 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1643809266; bh=dm7FRXlqgLoXSnVYEU35RfJ+tJo1MIzrKYsNCW4WqSI=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=IrgrbLsi2Wb8omPQ0EIhnidP9yuM65mgUGIX0NQsDYJbI7DfyRLmrbN6R/XH1Dey5 vAe6bpxWrbs3x3hP+3ifJRwHaRtdLmgvTwS4WkY1+dwmJMBWUzfxrpHpb3ZfA1g5k5 KDgZiOpp4Cf1AjsgkjzY5NQ9nPPoaCzueQ+RCkJ4= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 869973858D1E for ; Wed, 2 Feb 2022 13:40:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 869973858D1E Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-608-HNaF6ts-N_utLN8JGt7nuQ-1; Wed, 02 Feb 2022 08:40:46 -0500 X-MC-Unique: HNaF6ts-N_utLN8JGt7nuQ-1 Received: by mail-wr1-f70.google.com with SMTP id c9-20020adfa709000000b001dde29c3202so6871568wrd.22 for ; Wed, 02 Feb 2022 05:40:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=dm7FRXlqgLoXSnVYEU35RfJ+tJo1MIzrKYsNCW4WqSI=; b=gb4ZD6eAwzUbFcU2z9DEumWqQCHn6pvzzrG//y3/qa9tciT1KR5QmcG9dg0eOJPgQ8 OUhrKuC2TT4/PhACdMEgUUVNmeoIae2vnyYpGbsO7uzSwKADVAqpwH2k2+n0bCQjDc7P dIpPeBTzZFmJC6+3UaXQRk3zE6gmqun3dF33Lx/UsTvbZUqRcFmSFCaKf/D+uZVP8+sR 0F/aDQwtmzYiSDZi14jDPm040Rq/QVwiqFTjMuJMNi57hDzcTJPueNtxsPa7uns6J1ET U5F5BjhQ7sofF0erpW2ERqT2HJGciy1kGE3+TDoJma8oZKVclSk5r5Ny/xfF15Go4q0g rNIA== X-Gm-Message-State: AOAM5308yQlNSOYxWO/WaIi7d41ZX4FXumCXSMvbm1R9xmcC2VwX7IZ2 jxkbjm/SW3CKI/+dT4C0izxt4F9M+RST45YwnlNjitIzXVOk/U+2USyS4ozcQATSake3PazYrNq /TeYHdBz8JbuCEAEzNWNaAA== X-Received: by 2002:a5d:448b:: with SMTP id j11mr4526126wrq.172.1643809245019; Wed, 02 Feb 2022 05:40:45 -0800 (PST) X-Google-Smtp-Source: ABdhPJwYqyIcfwdzj1gnGkUWVpGf7wYeUGhr1NaiVfTsEN8X9UoJ+JN8Au3NyLY6HtsU0yf6yjScrQ== X-Received: by 2002:a5d:448b:: with SMTP id j11mr4526095wrq.172.1643809244597; Wed, 02 Feb 2022 05:40:44 -0800 (PST) Received: from localhost (host86-140-92-93.range86-140.btcentralplus.com. [86.140.92.93]) by smtp.gmail.com with ESMTPSA id i3sm16958348wru.33.2022.02.02.05.40.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Feb 2022 05:40:44 -0800 (PST) Date: Wed, 2 Feb 2022 13:40:43 +0000 To: Simon Marchi Subject: Re: [PATCH v4] gdb/tui/disassembly view: make symbol name appear on a line of its own Message-ID: <20220202134043.GG425591@redhat.com> References: <20220124192811.1530670-1-simon.marchi@polymtl.ca> <20220128224140.GF425591@redhat.com> <4f2da361-5a93-ee17-9bb5-e13653fc02d6@polymtl.ca> MIME-Version: 1.0 In-Reply-To: <4f2da361-5a93-ee17-9bb5-e13653fc02d6@polymtl.ca> X-Operating-System: Linux/5.8.18-100.fc31.x86_64 (x86_64) X-Uptime: 13:37:43 up 9 days, 4:24, X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Andrew Burgess via Gdb-patches Reply-To: Andrew Burgess Cc: Vasili Burdo , Simon Marchi , gdb-patches@sourceware.org Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" * Simon Marchi [2022-01-29 21:17:43 -0500]: > On 2022-01-28 20:20, Simon Marchi via Gdb-patches wrote: > >> This default `false` concerned my initially. The only times we call > >> tui_disassemble is either because we want to redraw the screen > >> contents, or we want to know what _would_ be drawn to the screen > >> if/when we do the redraw. > >> > >> Only, now, we draw the screen differently for these two cases, so, my > >> thinking goes, surely there's going to be some edge case where we ask, > >> what address would be on the screen if .... and we'll get the wrong > >> answer back. > >> > >> I played with this for a while, but couldn't get anything obvious to > >> break - I suspect that if there are bugs, they are going to be super > >> subtle, which addresses appear on the screen doesn't change much, > >> usually just one instruction different I think, so maybe it doesn't > >> matter. > >> > >> And given I couldn't spot anything, maybe I'm over thinking this, and > >> there is no problem... > >> > >> I guess my question is, did you already consider this already? Is > >> there a reason why having two strategies is known to be OK? > >=20 > > No, I haven't considered this, it is a good question. I really don't > > know the TUI code well (if at all), so my thinking was that if the TUI > > experts say it's ok, it's because it's ok :). But indeed, it would be > > good to understand exactly what happens here. > >=20 > > I'll git a little bit. Vasili, if you happen to know why we have these > > two behaviors (for_ui and !for_ui), feel free to answer. >=20 > Ok, so it in fact "breaks" page up / down, in the sense that the number > of lines scrolled up and down is not right. This makes sense, as the > other uses of tui_disassemble are to help with scrolling. It is used to > answer the question: assuming that we are currently showing disassembly > starting at this PC, what would be the starting PC if going up/down N > lines? >=20 > Without this patch, let's say that my asm windows shows: >=20 > =E2=94=82 0x110c <__do_global_dtors_aux+76> nopl 0x0(%rax) = =E2=94=82 > =E2=94=82 0x1110 endbr64 = =E2=94=82 > =E2=94=82 0x1114 jmp 0x1080 =E2=94=82 > =E2=94=82 0x1119
push %rbp = =E2=94=82 > =E2=94=82 0x111a mov %rsp,%rbp = =E2=94=82 > =E2=94=82 0x111d movq $0x0,-0x8(%rb= p) =E2=94=82 > =E2=94=82 0x1125 mov -0x8(%rbp),%r= ax =E2=94=82 > =E2=94=82 0x1129 mov (%rax),%eax = =E2=94=82 > =E2=94=82 0x112b pop %rbp = =E2=94=82 > =E2=94=82 0x112c ret = =E2=94=82 >=20 > Doing page down, the goal (at least my understanding of it) is that the > last shown line becomes the first one. The result is: >=20 > =E2=94=82 0x112c ret = =E2=94=82 > =E2=94=82 0x112d nopl (%rax) = =E2=94=82 > =E2=94=82 0x1130 <__libc_csu_init> endbr64 = =E2=94=82 > =E2=94=82 0x1134 <__libc_csu_init+4> push %r15 = =E2=94=82 > =E2=94=82 0x1136 <__libc_csu_init+6> lea 0x2ceb(%rip),%r15 = # 0x3e28 =E2=94=82 > =E2=94=82 0x113d <__libc_csu_init+13> push %r14 = =E2=94=82 > =E2=94=82 0x113f <__libc_csu_init+15> mov %rdx,%r14 = =E2=94=82 > =E2=94=82 0x1142 <__libc_csu_init+18> push %r13 = =E2=94=82 > =E2=94=82 0x1144 <__libc_csu_init+20> mov %rsi,%r13 = =E2=94=82 > =E2=94=82 0x1147 <__libc_csu_init+23> push %r12 = =E2=94=82 >=20 > With this patch applied, with the same starting position (0x110c being > the first instruction shown), I have: >=20 > =E2=94=82 __do_global_dtors_aux: = =E2=94=82 > =E2=94=82 0x110c <+76> nopl 0x0(%rax) = =E2=94=82 > =E2=94=82 frame_dummy: = =E2=94=82 > =E2=94=82 0x1110 <+0> endbr64 = =E2=94=82 > =E2=94=82 0x1114 <+4> jmp 0x1080 = =E2=94=82 > =E2=94=82 main: = =E2=94=82 > =E2=94=82 0x1119 <+0> push %rbp = =E2=94=82 > =E2=94=82 0x111a <+1> mov %rsp,%rbp = =E2=94=82 > =E2=94=82 0x111d <+4> movq $0x0,-0x8(%rbp) = =E2=94=82 > =E2=94=82 0x1125 <+12> mov -0x8(%rbp),%rax = =E2=94=82 >=20 > After page down: >=20 > =E2=94=82 main: = =E2=94=82 > =E2=94=82 0x112c <+19> ret = =E2=94=82 > =E2=94=82 nopl (%rax) = =E2=94=82 > =E2=94=82 __libc_csu_init: = =E2=94=82 > =E2=94=82 0x1130 <+0> endbr64 = =E2=94=82 > =E2=94=82 0x1134 <+4> push %r15 = =E2=94=82 > =E2=94=82 0x1136 <+6> lea 0x2ceb(%rip),%r15 # 0x3e28 = =E2=94=82 > =E2=94=82 0x113d <+13> push %r14 = =E2=94=82 > =E2=94=82 0x113f <+15> mov %rdx,%r14 = =E2=94=82 > =E2=94=82 0x1142 <+18> push %r13 = =E2=94=82 >=20 > Since 0x1125 is the last instruction shown before page down, it should > be the first one after page down. But it is 0x11c2 - the same as we > would have gotten before the patch. It's clear now: since the code to > compute where we land after a page down passes for_ui =3D=3D false, that > computation is done using the lines of the old layout, so the new > starting address is the same, 0x112c. But since the layout shown in the > UI is different, that means we completely miss instructions 0x1129 and > 0x112b. >=20 > So it is now obvious that the for_ui flag is wrong, we need to do the > scrolling computation considering the new layout. Thanks for looking into this. I hadn't considered the page up/down case when I was looking for issues. I guess you'll post another version without the for_ui flag? Vasili, if you can find reproducers for the scrolling problems you are seeing then we should probably look into those separately. Thanks, Andrew