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 8744C3858C33 for ; Wed, 5 Jun 2024 18:24:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8744C3858C33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 8744C3858C33 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1717611898; cv=none; b=fRTfO6iKWqrt26zsmGjvEu0rDKpAd0TrBDJ4RdtAl2aq87t7OM1SNsPdNHhhBfhl3psmR2LsSynfFQYM5sl+FO1snzLURD3FbRd6r2VoPoI1Yos9LNYVStCeEuD6meY0ILytd3AEoGdNxOAN0ZdsMyetOdIpTb/RR845fDomSrA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1717611898; c=relaxed/simple; bh=LfXMzsrZ+mtxxF0Aykg3LZwCVIEKweO8RVUA29GRgPc=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=jcOcxvAQ5ypYxRcUKzeH2nRQ7Sm+GwBxMo8ENrOnPtE9fXd/NuYRPzs0qyH3D3f1d61MHzy0LD3NRf0qPh5fKoQW2/EmQgojm1h3qLjRBx3yNEdotUW57iKUkG/PXKgL1N1qJbT4vlN2hobOxi1Ntq9aKvz0Ufaem6GGCKyrA9o= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1717611896; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LMpz8+Wj98lY1z/U2EiQmSl5jm+t/HRpy1wuzagVJ7A=; b=gVuINoPqlbbCsNtawEDogEz6YkmOswI2paD4dL0i0jshfTVQLy2fItJdszj7Gg+yaswubn i9dPi7OsFsGMtAyF8Xr3Nwh7DISK0pHHn6pPfpSqqLcDPeSyYXI22XUI1pIB/CIZVdD/r9 BXne1H6+pDMI5VYQ8DxUDZAup6sDh9o= Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-689-2sX1hSGXOly5cYizCTw07A-1; Wed, 05 Jun 2024 14:24:54 -0400 X-MC-Unique: 2sX1hSGXOly5cYizCTw07A-1 Received: by mail-qk1-f198.google.com with SMTP id af79cd13be357-79522e6a71cso13195785a.1 for ; Wed, 05 Jun 2024 11:24:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717611894; x=1718216694; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=LMpz8+Wj98lY1z/U2EiQmSl5jm+t/HRpy1wuzagVJ7A=; b=FQHLQlrMqr33vlqYATp+37KSKs3ULiJ8StNbOMR7GA3w4nodt8y5D9a85Ieo+tyIpL qMlGl2o8h1DU+rRI8/uAFgzUKemKrPjW+8kQmOp+Y6TvXzu/OOxJRNsNBHKc0vnpm3Cx 3JaNnlkCWkFDeATK0k2GlK9mZPYpB1jvhlaxMR/529LM7vvvSYvHBwktZvWcQcWcRJdA nhObgeU+q60kVsGpB3njJewl2+2cK9JhnYc0vusSl4MuepP04H4H2wvnlHAWlx6oMQDA dXl1f7lMPZn4d94pn6g0I4rLWoBw6YeamlrIjgU0uknyukl7wsxjeRsU/hqgPMb3i3zA 9/FQ== X-Gm-Message-State: AOJu0YxnmIva+C6hEPlNG7FVk2xHGI6t8jsGIQKqRtl5JI16BhuctyOa Lj6NRMtVVoSDKiLQiTH5e+hcHLVbx0r8E8tqewbu4nvlN1SzRSgthByKhW3MrXFSu/RxXfKPyOd Q/Un4SZgNC2RA9zeKLAWsZZL1QpGWH0h8riNgq2GJZZHiUp1r7ExgtK0ABqPVleyXMpI= X-Received: by 2002:a05:620a:1728:b0:795:1f7c:c6fa with SMTP id af79cd13be357-7952f0b88e8mr92158485a.4.1717611893866; Wed, 05 Jun 2024 11:24:53 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGQdns59st6wfMnbPhGYCDS5vLuwu/q8jtsW6FSAjVlZR+Kq7KFghpsGGsLphyq14jJt2fBpA== X-Received: by 2002:a05:620a:1728:b0:795:1f7c:c6fa with SMTP id af79cd13be357-7952f0b88e8mr92156385a.4.1717611893485; Wed, 05 Jun 2024 11:24:53 -0700 (PDT) Received: from ?IPV6:2804:14d:8084:92c5::1001? ([2804:14d:8084:92c5::1001]) by smtp.gmail.com with ESMTPSA id af79cd13be357-794f3177350sm463399485a.124.2024.06.05.11.24.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 05 Jun 2024 11:24:53 -0700 (PDT) Message-ID: <736a096d-91bb-4787-b628-c273f7e91c78@redhat.com> Date: Wed, 5 Jun 2024 15:24:50 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/3] gdb/record: add support to vmovd and vmovq instructions To: Tom Tromey Cc: gdb-patches@sourceware.org References: <20240521202800.2865871-1-blarsen@redhat.com> <20240521202800.2865871-3-blarsen@redhat.com> <87msnznzag.fsf@tromey.com> From: Guinevere Larsen In-Reply-To: <87msnznzag.fsf@tromey.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.4 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,T_SCC_BODY_TEXT_LINE 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 6/5/24 13:13, Tom Tromey wrote: >>>>>> "Guinevere" == Guinevere Larsen writes: > Guinevere> This commit adds support to the x86_64 AVX instructions vmovd and vmovq. > Guinevere> The programmers manuals for Intel and AMD describe these 2 instructions > Guinevere> as being almost the same, but my local testing, using gcc 13.2 on Fedora > Guinevere> 39, showed several differences and inconsistencies. > > Guinevere> static bool > Guinevere> -i386_record_vex (struct i386_record_s *ir, uint8_t rex_w, uint8_t rex_r, > Guinevere> +i386_record_vex (struct i386_record_s *ir, uint8_t vex_w, uint8_t vex_r, > Guinevere> int opcode, struct gdbarch *gdbarch) > Guinevere> { > ... > Guinevere> + error ("Unrecognized VEX.PP value %d at address %s.", > Guinevere> + ir->pp, paddress(gdbarch, ir->orig_addr)); > > I don't know anything about record, really, but it seems weird to have a > function that has two error return mechanisms -- either calling error or > printing a message and returning some value: > > Guinevere> default: > Guinevere> gdb_printf (gdb_stderr, > Guinevere> _("Process record does not support VEX instruction 0x%02x " > > What's the deal with that? Christmas vacation in between, mostly. gdb_printf is what i386_process_record already uses, so felt reasonable, then I chose "error" int the other situation because it felt more appropriate for me to have a strong error when we find something that, to the best of my knowledge, breaks the ISA. To me it marks a difference between "we're not equipped to handle" versus "up to most recent ISA, this is straight up incorrect", but if you think it's better to only use one error mechanism, I can switch to gdb_printf everywhere. -- Cheers, Guinevere Larsen She/Her/Hers > > Tom >