From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2001:67c:2178:6::1c]) by sourceware.org (Postfix) with ESMTPS id A63B73858C62 for ; Sat, 11 Feb 2023 08:15:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A63B73858C62 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id CA4A9339B3; Sat, 11 Feb 2023 08:14:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1676103299; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xuhUbc9driQVEselaIf0dprJOz54/WVUKFwaP+kdaQU=; b=CpuGh0Eg+v19rdFVsSbW0P2Xzxk2gKVFjgBCVYdOt/Mqsz8YfKO7Etj5McSzZr3NDyewOq T52yQaunw5OIQ0q080SLbkgJxT6EmLaC1qK6r4Qdp9nF9gXuT5f5cHKkk8xPNv55hbcw6Y rXeOIgR3ELprjokKyVF359deISEADaA= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1676103299; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xuhUbc9driQVEselaIf0dprJOz54/WVUKFwaP+kdaQU=; b=PblWfdeKZYUmE8H3wb8643RAZUQW0Z6zjuuOhAfn6HvIDEuo95i2UJZa5zXkM+jbeQkEoA NJ4o4DLVENtGcABQ== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id B1FFD13A1F; Sat, 11 Feb 2023 08:14:59 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id YkIbKoNO52PFBAAAMHmgww (envelope-from ); Sat, 11 Feb 2023 08:14:59 +0000 Message-ID: <4407efbb-d2bb-3606-7d79-381d5c4bd4b8@suse.de> Date: Sat, 11 Feb 2023 09:14:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [PATCH] [gdb/tdep] Don't use i386 unwinder for amd64 To: John Baldwin , gdb-patches@sourceware.org References: <20230210125602.20437-1-tdevries@suse.de> <6387593e-e17c-a951-8346-0ba0cd7817f9@FreeBSD.org> Content-Language: en-US From: Tom de Vries In-Reply-To: <6387593e-e17c-a951-8346-0ba0cd7817f9@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_NUMSUBJECT,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2/10/23 18:01, John Baldwin wrote: > On 2/10/23 4:56 AM, Tom de Vries via Gdb-patches wrote: >> For i386 we have these unwinders: >> ... >> $ gdb -q -batch -ex "set arch i386" -ex "maint info frame-unwinders" >> The target architecture is set to "i386". >> dummy                   DUMMY_FRAME >> dwarf2 tailcall         TAILCALL_FRAME >> inline                  INLINE_FRAME >> i386 epilogue           NORMAL_FRAME >> dwarf2                  NORMAL_FRAME >> dwarf2 signal           SIGTRAMP_FRAME >> i386 stack tramp        NORMAL_FRAME >> i386 sigtramp           SIGTRAMP_FRAME >> i386 prologue           NORMAL_FRAME >> ... >> and for amd64: >> ... >> $ gdb -q -batch -ex "set arch i386:x86-64" -ex "maint info >> frame-unwinders" >> The target architecture is set to "i386:x86-64". >> dummy                   DUMMY_FRAME >> dwarf2 tailcall         TAILCALL_FRAME >> inline                  INLINE_FRAME >> python                  NORMAL_FRAME >> amd64 epilogue          NORMAL_FRAME >> i386 epilogue           NORMAL_FRAME >> dwarf2                  NORMAL_FRAME >> dwarf2 signal           SIGTRAMP_FRAME >> amd64 sigtramp          SIGTRAMP_FRAME >> amd64 prologue          NORMAL_FRAME >> i386 stack tramp        NORMAL_FRAME >> i386 sigtramp           SIGTRAMP_FRAME >> i386 prologue           NORMAL_FRAME >> ... >> >> ISTM me there's no reason for the i386 unwinders to be there for amd64. >> >> Furthermore, there's a generic need to play around with enabling and >> disabling >> unwinders, see PR8434.  Currently, that's only available for both the >> dwarf2 unwinders at once using "maint set dwarf unwinders on/off". >> >> If I manually disable the "amd64 epilogue" unwinder, the "i386 epilogue" >> unwinder becomes active and gives the wrong answer, while I'm actually >> interested in the result of the dwarf2 unwinder.  Of course I can also >> manually disable the "i386 epilogue", but I take the fact that I have >> to do >> that as evidence that on amd64, the "i386 epilogue" is not only >> unnecessary, >> but in the way. >> >> Fix this by only adding the i386 unwinders only if >> "info.bfd_arch_info->bits_per_word == 32". >> >> Note that for the x32 abi (x86_64/-mx32) the unwinder list is the same >> as for >> amd64 (x86_64/-m64), without and with this commit. >> >> Tested on x86_64-linux, -m64 and -m32.  Not tested with -mx32. > > I strongly suspect you don't want these unwinders for x32 either.  I don't > know what bits_per_word is for x32.  If it is 32 then you at least aren't > changing anything for x32.  If it is 64 then I think your change is > correct. Hi, thanks for the review. It's the latter, 64. > You might consider checking 'tdep->num_dword_regs == 0' instead if you want > to enable these for i386-only and exclude x32.  (IIRC, x32 is encoded in > ELF > as EM_X86_64 but with ELFCLASS32 or the like which would mean x32 would > have > bits_per_word of 32 I think). > > LGTM as-is or if you decide to test num_dword_regs == 0 instead. > I'm leaving it as is. I've reformulated a bit to make the x32 abi discussion more clear: ... Note that the x32 abi (x86_64/-mx32): - has the same unwinder list as amd64 (x86_64/-m64) before this commit, - has info.bfd_arch_info->bits_per_word == 64, the same as amd64, and consequently, - has the same unwinder list as amd64 after this commit. ... and committed. Thanks, - Tom