From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 9720MMT30meNUg4AWB0awg (envelope-from ) for ; Thu, 13 Mar 2025 11:20:36 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=bFJVEpeo; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id B2F221E105; Thu, 13 Mar 2025 11:20:36 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.0 Received: from server2.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 ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 23E5B1E08E for ; Thu, 13 Mar 2025 11:20:36 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 3B6EF3858414 for ; Thu, 13 Mar 2025 15:20:32 +0000 (GMT) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTP id 24E903858408 for ; Thu, 13 Mar 2025 15:20:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 24E903858408 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 24E903858408 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=1741879215; cv=none; b=owxWOndY1t7sR5uyutDIWJTBMio8BykN7cz2tCqYXYQAaNzGdsfAfSsbotMM/vJGCPoLjpLqaMXJKOvCEQVdp5KY0XHLMnmj+qSQ7O9tyL8FxeVbhqfXBDCo8ntbFZjTzo92MMATlSW8YlI9wiUI4eGc3DJnLDEf4+1EAZ5Gxto= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1741879215; c=relaxed/simple; bh=ZqVBW2BbFFSDWjcdQ1Xi75ksgJsSJ4eUTWVld1eau/I=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=dIOnjdp8rHEKcUw4TdLPqw4TYuNWJPwA1BWRvQnqc2zBMJrD4MtsZFGLihdn0BmXjWptr1X61SJb8fjWv4jiOb4mO1zDH6sFLq/s739DYHPMnemMRbHA1JSZm+2nRBY/iKG/t82KCgDBiBtneqzeSatrtksyeeSZNOkv7TW9Bbc= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1741879212; h=from:from:reply-to:subject:subject: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=T3r716r/8kX9j7814rkSWchDyfIEJez8EqZAbvisTmk=; b=bFJVEpeohWS0+kDLhPPZrtZLhZg/AOpJosM1ATjxU8l2xJy3DnE9ePWQK85oiNw3FUWtue Agd8BwcGdQM24fiiZA4BGHWEgSg+0Ao02tKF+xDVLS5uTNMPztrOZr4esWNkf2Pth4E7kt YZkRQEWhXK5uKoW+qOgF1Xf0NrlA9yM= Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-617-xrS9vzD7NDSyAfzLgQlbnA-1; Thu, 13 Mar 2025 11:20:11 -0400 X-MC-Unique: xrS9vzD7NDSyAfzLgQlbnA-1 X-Mimecast-MFC-AGG-ID: xrS9vzD7NDSyAfzLgQlbnA_1741879211 Received: by mail-qv1-f71.google.com with SMTP id 6a1803df08f44-6e8f184b916so31746156d6.3 for ; Thu, 13 Mar 2025 08:20:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741879211; x=1742484011; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=T3r716r/8kX9j7814rkSWchDyfIEJez8EqZAbvisTmk=; b=SU0G7e5MhafgYVtyKCAWbK6kD+VfT5Les5BWrxFQ9S1JeKEkJgSlRoTAxt94OWabQ7 VXf1ObH66tXIT6/eJaQ/lJY/SicI4kOjYOsDyk41EMz9uuZSjGTLv+8S5s+xTBOiMBLp Kp3T/hPRm5fNrXwqZirLzALfS+s83OSKFVTsOnRFvipAv8ErUIqcvo59c8mGe3dm09Fk Ie2Id0LV9RoHXLzhFPpb29MUFD+Gh93swSsgcdU7hdEkOUiqOiFQ/dH2PmiS+MMgv4T+ p/beYJyqz3Gy+49T9rPfb6p/+SPW3mho9TIEsfbHhwDbzmNsB3UvcqRyq/HlLRewsYmP zi0Q== X-Forwarded-Encrypted: i=1; AJvYcCVtYPFdlw5XEaJceqd5eC9TOXtEadLgFTACKRu1K26cdt/yfqF734dv0V7Vj8YEXInJVE0dJCjxIT+WZQ==@sourceware.org X-Gm-Message-State: AOJu0Yx4X8Cmj8JiisAicLlfLR7n0ZliE6VRgSOeEsXNO8ZfP/C0iVWV 4SqZ2Dt7uFyX9mrhDfyl2717N8PH8odR9KMe4j9VQ6zPZzPHdwSx8h6t+MefYD9x9r8IeFIbnoQ n46SCtPqZ/QInkCLkGPeWm0jZVs9ELuVDDVyw5RNcR+eSpFwY0P+5mIRO6z5gEhMPWhk= X-Gm-Gg: ASbGncsjR8x6A5ea+bObud8f0D1G8pxqRFt91f03inCYnblMhQ2ooYN9BXiXntapwDA MmzyP1rc2C/tF3JYJJqtRG8Bi7GwKKmIboJSeFrmqbve7q+ka0ne7WlnODREE2heYuRj2cMMfmC llzSqhrJjLJ+Bfw4KRagy/JrLcx2I2GoEALAyykVwke37aZIbf9xpUnjZJMISsyLadELIhLAgns lwAePm3TTA4rTAelcFApJUlYLwJte979ghT116jUN87azoTMsfIcIlpLBf5iFq4lnr9Ey8b9dku Y0w0NsYyZ/4TTuQO5HVrOhPF64o= X-Received: by 2002:a05:6214:21a9:b0:6ea:d393:9634 with SMTP id 6a1803df08f44-6eae79bfc59mr826696d6.3.1741879210845; Thu, 13 Mar 2025 08:20:10 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHZ9aLVUNpfXv4dpaGl1z4ouUHza2gtVEnM1aXZ0Hfg1JA6A88NLQC0SkLSIwSr4NlHnVUtaQ== X-Received: by 2002:a05:6214:21a9:b0:6ea:d393:9634 with SMTP id 6a1803df08f44-6eae79bfc59mr826396d6.3.1741879210534; Thu, 13 Mar 2025 08:20:10 -0700 (PDT) Received: from ?IPV6:2804:14d:8084:9a69::1001? ([2804:14d:8084:9a69::1001]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6eade34b6cbsm10564656d6.97.2025.03.13.08.20.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 13 Mar 2025 08:20:10 -0700 (PDT) Message-ID: <43745ab1-66a3-4056-be24-ed178300faa2@redhat.com> Date: Thu, 13 Mar 2025 12:20:08 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] [gdb/tdep] Backport i386_canonicalize_syscall rewrite to gdb-16-branch To: Tom de Vries , gdb-patches@sourceware.org References: <20250313095325.23876-1-tdevries@suse.de> <6cab43c6-85c9-4834-9f44-9cc1267621b7@redhat.com> <8d94c39e-86f3-4f4c-8443-4f9ce786743f@suse.de> From: Guinevere Larsen In-Reply-To: <8d94c39e-86f3-4f4c-8443-4f9ce786743f@suse.de> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: iHRIbNyZgBGFwekK0j49aBhp2Bm2LItee9w5yEWM-Lc_1741879211 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org On 3/13/25 10:06 AM, Tom de Vries wrote: > On 3/13/25 13:40, Guinevere Larsen wrote: >> On 3/13/25 6:53 AM, Tom de Vries wrote: >>> Commit fbfb29b304e ("[gdb/tdep] Rewrite i386_canonicalize_syscall") >>> fixes >>> PR32770, which reproduces on the gdb-16-branch, but the commit is >>> not ideal >>> for backporting because it completely rewrites >>> i386_canonicalize_syscall. >>> >>> Instead, this is a version of the patch that adds a single line >>> entry for each >>> syscall value for which i386_canonicalize_syscall gives a different >>> result >>> with and without the patch. >>> >>> Consequently, the two versions give identical results.  I've checked >>> this for >>> syscalls 0 to 466. >>> >>> Tested on x86_64-linux with target board unix/-m32, on top of >>> gdb-16- branch. >>> >>> PR tdep/32770 >>> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32770 >>> --- >> >> Hi! >> >> I looked over all the special cases, and it mostly looks ok. There >> are quite a few syscalls where we have an older or similar enough >> version, like execveat and execve, or faccessat and faccessat2, but I >> can see from the accept4 patch why you wouldn't have done that... >> however, for the semtimedop_time64 syscall, you just converted to the >> semtimedop version. What is special about that one? >> > > Good question. > > This was one of the syscalls I came across while reviewing the > gdb_syscall enum values >= 500.  And since the recording support > doesn't actually record the timeout parameter, the time64 part of > semtimedop_time64 seemed irrelevant. > > So, what was special here was that gdb_sys_semtimedop was supported, > but there was no corresponding mapping from i386. > > For the execveat case, gdb_sys_execveat is missing.  That makes it > similar to the accept4 case. I see... so other syscalls ending with _time64 where GDB wouldn't record the time64 portion could just be swapped for the regular version? I'm asking because I noticed a couple, but I didn't double check what exactly they recorded, but it could be a quick improvement in that case. The reason I ask for execveat, is that we don't actually record anything, so for GDB it would be the same as execve, which we do support. I'm basically trying to narrow down when to include a gdb_sys version, and when I can return a close-enough syscall... -- Cheers, Guinevere Larsen She/Her/Hers > > I hope that answers your question. > > Thanks, > - Tom >