From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id A5B343857728 for ; Wed, 27 Sep 2023 17:44:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A5B343857728 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1695836677; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=QAwDO9bxFLPcSt/l17WHN2TpdVsukB4xqfkMXSXTIZg=; b=cN0EpgMBetOVb2XMIHhQddJzgkgeyplHJLurq9a4b5zELop3aVvybFH7WZ13djW8ZiL7gG oFfQqEiFUsOcgePkOngmo8YERcrNbnzE3xvzVc6Jg8BI9OyMitTzvUjYHz6vxi2s0Dg9oP lg10NKWAX6bEmUnASSAeFeN83+lyJgw= Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-615--c5a3ZGDO_uLBVURy783tg-1; Wed, 27 Sep 2023 13:44:36 -0400 X-MC-Unique: -c5a3ZGDO_uLBVURy783tg-1 Received: by mail-qv1-f72.google.com with SMTP id 6a1803df08f44-65af1fad7f1so169659346d6.2 for ; Wed, 27 Sep 2023 10:44:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695836675; x=1696441475; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=QAwDO9bxFLPcSt/l17WHN2TpdVsukB4xqfkMXSXTIZg=; b=KV1C/CtEH9oBTwN9TVh1VKiD6RdkhrIvhpLxg8QySYvb/nW0bXNWMnMKJtm04vC0N9 1ydej7z1DWc5q6ZmRVSeBLQRmHaB1R7/xx8CBh7sOqkl9pV+fzCg8aGWRB+FwTruQFwe iGbNasJU3WX+oImFm/4Ykvd9YX2taOzC1046vophEPcYNH52aYEkHyxKN2BGoW0mdjjM i6S0fpVNYXeFK94KOh2CPRub+I7euKoi5nhgoztmoyQdi7XNNtyEbpxfch677OL0etMD TGpsZbBYdl3ZCIE7m/2/QOdcA93BSbLVtdnZWYIolGzHEUVwBytoUHYJXtNBYcuyFilg 6juA== X-Gm-Message-State: AOJu0YygmsAAF8PZQnexKtx+6DSFcRCLEW/JRzec1v4ePFqpxkrJOMVv di+qoA4D2DEsY+fNFsCwJwxkWQCR480fHM7Noc4T7Lv5nPykxjw63RTaDTD3tabDJPZEISBdkr9 HLlCFDPsyrcjh3nYZYL98TMwqYW94UA== X-Received: by 2002:a0c:f2cf:0:b0:656:3ed4:ffe9 with SMTP id c15-20020a0cf2cf000000b006563ed4ffe9mr2610208qvm.58.1695836675421; Wed, 27 Sep 2023 10:44:35 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFMJci16ZQqN9R0QosjiK6YX6YNRiFnMHdI6nfzMEI4y4ImbdI0eoPqNx/o98a5PIxCC/UlcA== X-Received: by 2002:a0c:f2cf:0:b0:656:3ed4:ffe9 with SMTP id c15-20020a0cf2cf000000b006563ed4ffe9mr2610196qvm.58.1695836675172; Wed, 27 Sep 2023 10:44:35 -0700 (PDT) Received: from localhost ([31.111.84.209]) by smtp.gmail.com with ESMTPSA id n6-20020a0ce486000000b0065cfb75fe81sm710638qvl.67.2023.09.27.10.44.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Sep 2023 10:44:34 -0700 (PDT) From: Andrew Burgess To: Simon Marchi , Luis Machado , gdb-patches@sourceware.org Cc: thiago.bauermann@linaro.org Subject: Re: [PATCH v7 15/18] [gdb/generic] corefile/bug: Add hook to control the use of target description notes from corefiles In-Reply-To: <082c6cbd-7a30-4b21-962a-3c87f4da9aa8@polymtl.ca> References: <20230918212651.660141-1-luis.machado@arm.com> <20230918212651.660141-16-luis.machado@arm.com> <87pm2cyldy.fsf@redhat.com> <87led0yif2.fsf@redhat.com> <423fed06-ce80-52d0-013d-03384fecc853@arm.com> <87il83yhbj.fsf@redhat.com> <10c90dbb-75fc-43fa-a3b4-90359ad21f51@arm.com> <082c6cbd-7a30-4b21-962a-3c87f4da9aa8@polymtl.ca> Date: Wed, 27 Sep 2023 18:44:33 +0100 Message-ID: <87il7vwlxa.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,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: Simon Marchi writes: > On 9/21/23 06:44, Luis Machado via Gdb-patches wrote: >>>>> For point (2) I agree with the premise that we need a mechanism to stop >>>>> AArch64 loading the incorrect single NT_GDB_TDESC. This is a slight >>>>> change in stance from what I originally wrote, but our IRC conversation >>>>> showed me I was wrong originally. I don't have time this evening to >>>>> look at this, but will follow up again tomorrow with more thoughts. >>> >>> I wonder, instead of adding the new hook, maybe we should just reorder >>> the checks in core_target::read_description -- ask the gdbarch to grok a >>> tdesc from the .regs (etc) sections, and if that fails, check for an >>> encoded tdesc. >>> >> >> That's exactly what I did a few versions earlier. But Simon pointed out it would >> effectively be a conflicting situation given our choice of defaulting to reading the >> target description from the NT_GDB_TDESC. So I went with the hook, which, to be honest, >> seems cleaner. > > Hi, > > I did not have the complete historical picture when I suggested this, > Andrew later explained that this was added for some RISC-V target for > which a tdesc could not be reconstructed from just the dumped register > state. I thought that the NT_GDB_TDESC note was a better source of > truth than just the register state. My understanding now is that for > most targets (including AArch64 with SME and friends), reconstructing > the tdesc from the register state works equally well as reading an > NT_GDB_TDESC note (that holds the right tdesc). So, we can say that > having the NT_GDB_TDESC note there is useless in these cases. > > So now, my question is: when we generate a core, should we only generate > an NT_GDB_TDESC note for those targets for which we know a tdesc note > will be necessary? That would involve a gdbarch hook where the arch can > say "yes please generate a tdesc note in this core", which would default > to false. I would not oppose such a change, but the problem here really was that GDB was just writing out the wrong thing -- the generic, incorrect, global tdesc, rather than the correct thread specific tdesc. But you are correct, for hosted environments (Linux, FreeBSD), where the OS can create a core file without a NT_GDB_TDESC, we really do need to be able to figure out the architecture just from the core file contents, so dropping the NT_GDB_TDESC for these cases really shouldn't be a problem. Thanks, Andrew