From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) by sourceware.org (Postfix) with ESMTPS id 1E4263986421 for ; Wed, 11 Aug 2021 17:00:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1E4263986421 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=adacore.com Received: by mail-oi1-x229.google.com with SMTP id bi32so5602172oib.2 for ; Wed, 11 Aug 2021 10:00:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adacore-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=To18JRiRFobA+HNWH7aAhL00I+6VcEt6QwN14N2e46c=; b=PogIKUeEgXwAEuTYaFZSGQvLWQ9aFEPoZyyZdz8JThMhnb4gNSTB+aW70r7l0we3SZ lbxZf7K9oDdUtvY4ggbjdfSsBjH2UNuW0kP40V4fAp/lLARS2et6/H5YX9X9viU0E5U/ YXTV1QiKB+pBYKIjrF4ktv8t7Zk9AriPSpB3HJq3v+ies/XdQsXSmRFx3/7Ph+QCAa5L nEqLeR4Cye9Gl9+mP77pkjyqyOQaEiFpZVLH96sUHD6biN6VuM+gYmgQjSEQs1exThWY oD9kCK4BSn3kEwo39g7recrJx537kECHyJ0QxpMHw5S5BZ2K83eL8uNdlEqR7mgocdmT 9hhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=To18JRiRFobA+HNWH7aAhL00I+6VcEt6QwN14N2e46c=; b=ZSMcjxU/fJ4aLIuRR5cQS/wj0I1jiwcDXVt9G5+V2kXJwVMBMaKrtJtO2BNDEwUZYF 2sqbIJrAM+3StHI87q1sVpHfiqfO8jJIzWstqSgXC+vvKRfUWWgz6vNpy8Lp+sMqIz9P ExFlM9Qw9XupcGsmrdtKZbhONBNVgnGWAUoXLeYhjPQamxHpWyBLjTGBtc6+z5CkbZ39 oMKnZOqaESuEZA5lzR9hLkUlcGtbA89/79Ji/NppGMmMgIEAUUXpW4Dn9Dq4lWjnrzCI w1jKSCPxkDhCKpingV7KhlXJ5IZVNIrjDk0df8HBeTiPjyICwfU7pJ1kMFyYdgJbHJ+A Og8Q== X-Gm-Message-State: AOAM531BofBgWCT3D6M1HXlZ4OVOw4BnaBSuQBJeCt2VXVxn6SFdNnN8 iCDdfuQpDg4bpna8b/KLt0n3tZ1nlfNuuFl3 X-Google-Smtp-Source: ABdhPJztzENO7fjsnra9kcedzy2urqoPPMuYtJF5G01P4/9g8W0ZMB6on275gU0qmaFTyBVdlcJoQQ== X-Received: by 2002:a05:6808:4c6:: with SMTP id a6mr8331312oie.164.1628701232576; Wed, 11 Aug 2021 10:00:32 -0700 (PDT) Received: from murgatroyd (97-122-71-196.hlrn.qwest.net. [97.122.71.196]) by smtp.gmail.com with ESMTPSA id m1sm986923ooo.45.2021.08.11.10.00.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Aug 2021 10:00:31 -0700 (PDT) From: Tom Tromey To: Zoran Zaric via Gdb-patches Subject: Re: [PATCH v3 15/17] Make DWARF evaluator return a single struct value References: <20210528154648.60881-1-zoran.zaric@amd.com> <20210528154648.60881-16-zoran.zaric@amd.com> X-Attribution: Tom Date: Wed, 11 Aug 2021 11:00:30 -0600 In-Reply-To: <20210528154648.60881-16-zoran.zaric@amd.com> (Zoran Zaric via Gdb-patches's message of "Fri, 28 May 2021 16:46:46 +0100") Message-ID: <87v94bdihd.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, RCVD_IN_ABUSEAT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org 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: , X-List-Received-Date: Wed, 11 Aug 2021 17:00:34 -0000 >>>>> "Zoran" == Zoran Zaric via Gdb-patches writes: Zoran> The patch is addressing the issue of class users writing and reading Zoran> the internal data of the dwarf_expr_context class. Zoran> At this point, all conditions are met for the DWARF evaluator to return Zoran> an evaluation result in a form of a single struct value object. Hi. On an internal test case, using an arm-elf target, this patch causes a regression. (It doesn't happen for any of the other cross targets that I test when importing upstream gdb.) I don't know if there's an upstream gdb test case showing the same problem... I can only really run native tests with dejagnu AFAIK. Anyway the failure manifests like this: Breakpoint 1, file_1.export_1 (param_1=, str="test_gdb_fpregs") at [...]file_1.adb:5 Whereas when it works it looks like: Breakpoint 1, file_1.export_1 (param_1=99.0, str=...) at [...]/file_1.adb:5 I think the difference is that the new code does: Zoran> +/* See expr.h. */ Zoran> + Zoran> +struct value * Zoran> +dwarf_expr_context::fetch_result (struct type *type, Zoran> + struct type *subobj_type, Zoran> + LONGEST subobj_offset) Zoran> +{ [...] Zoran> + case DWARF_VALUE_REGISTER: Zoran> + { Zoran> + int dwarf_regnum Zoran> + = longest_to_int (value_as_long (this->fetch (0))); Zoran> + int gdb_regnum = dwarf_reg_to_regnum_or_error (this->gdbarch, Zoran> + dwarf_regnum); ... whereas the old code did: Zoran> - switch (ctx.location) Zoran> - { Zoran> - case DWARF_VALUE_REGISTER: Zoran> - { Zoran> - struct gdbarch *arch = get_frame_arch (frame); Zoran> - int dwarf_regnum Zoran> - = longest_to_int (value_as_long (ctx.fetch (0))); Zoran> - int gdb_regnum = dwarf_reg_to_regnum_or_error (arch, dwarf_regnum); That is, the old code used get_frame_arch, which is different from this->gdbarch. Now, it seems to me that when working with registers, the frame's architecture is the one to use. Other spots seem to use read_addr_from_reg, which does this same thing. I'm going to try out that change for a number of cross targets and see if it looks ok. Meanwhile I thought I'd send this email in case anyone else has more insight. thanks, Tom