From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) by sourceware.org (Postfix) with ESMTPS id C206D3858418 for ; Wed, 28 Sep 2022 19:34:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C206D3858418 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-qk1-x736.google.com with SMTP id i3so8529971qkl.3 for ; Wed, 28 Sep 2022 12:34:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=Av9q8zStK+onxAGw6nnF25xeLaU4wbmFLqWcd5NYLPA=; b=HdwxyhSITX85ATx59Q8f2Qz1dFLiBiBf63x63J4V+xa6B0nIovfgsamvShssjTjmst EhvKm+mf7+GT47ThDrC5T3kOKUpMXaDfCEHV+5Al5hEghq7Ka2OYl6GTnk6/f6eJxmuS YL/m38t2PbncHC59Y26JBxarDxq3wG7Xp1p3WDRoZGAAlkctjbR/7sZqSnUiHLsH6Ayb ppqzAY+gsVYIQq10O4BkgyZHSy4k1i8kYcM8tGuBfqIXpc40WaPFwC5FiXbVdaGL6X62 0KkbVyS9KfzdRzMSYqJJPEI+WWsXTYBREaz2YrVGYrz31OYmTX+ja4iyQxxzR5Z8YDQD M5Wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=Av9q8zStK+onxAGw6nnF25xeLaU4wbmFLqWcd5NYLPA=; b=7uXDJbeXd6HFTaxASX/d7E7GvAsycvSPg95dYTd21aDIdo/Kg6wJyygqHn5J0HsuUL 4pslNz+O8kQSeGbAL7lR2+D4758O9OHr9y9IjN+Ypwu9AKJPobdwDSHrBMKolM822EY1 LXZrF7HQ7Euo7XGPD27YLRaE29EH5yT/lDN5L7yoXGzjzvG1J6AxG29aJjwAq+Vy/3CW 67d8fDF4kmXrs1PF9wL8b/PTkH4r0p6gx78nGz2yz4GUmBONRHNocbjsbL47MiU92LJg gMgBwTi8XvlDJgt1gS+JJ1v9hd/bCpNYuc+9LugN5z3clbSHxGgbDyDCVN9e177oqWar rTNA== X-Gm-Message-State: ACrzQf0dvaWc9s0rJPfXmV+O2DlLN1rTzmU8M5kpnuyG0l1LAux4ZNk6 UVPIqHTYIWdHm/QsI+YAMvsOnJNdTvGqU/24GeE62fUR X-Google-Smtp-Source: AMsMyM6yTjmptwgjSH0nculqihI0kfbE9UuKEB4AUmqnjK++/npDv8SIClxnXMNyhevMeGkD16eIGeoFZYyAQIWSdFI= X-Received: by 2002:a05:620a:2552:b0:6ca:bf8f:4d27 with SMTP id s18-20020a05620a255200b006cabf8f4d27mr22289908qko.383.1664393642094; Wed, 28 Sep 2022 12:34:02 -0700 (PDT) MIME-Version: 1.0 References: <32216291-fd1f-4579-87de-d24cb7190894@suse.com> <995353db-27f3-ea60-8e69-32bcc44dfd49@suse.com> <162c053b-7c68-67b8-1443-926f2ebb321d@suse.com> <892afda8-0e6a-cc7c-df95-f5581e831fff@suse.com> <93622263-1a05-07e7-4a96-c33cffb0796b@suse.com> In-Reply-To: <93622263-1a05-07e7-4a96-c33cffb0796b@suse.com> From: "H.J. Lu" Date: Wed, 28 Sep 2022 12:33:26 -0700 Message-ID: Subject: Re: [PATCH 5/7] x86: re-work insn/suffix recognition To: Jan Beulich Cc: Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3018.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,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 Wed, Sep 28, 2022 at 5:49 AM Jan Beulich wrote: > > On 27.09.2022 01:52, H.J. Lu wrote: > > Sorry for the delay. I was on vacation. My main concern is to call > > strdup and free for each instruction. I prefer to add new entries to > > deal with rare cases instead of penalizing all instructions. > > Hmm, I think I can take care of this concern: As it looks, at least > parse_insn() leaves the input buffer undisturbed, so minimally I ought > to be able to limit the strdup() to just a very small set of > mnemonics. I'm not sure yet if I may even be able to avoid the copying > altogether; I'll have to check quite carefully in particular > parse_operands() and the functions it calls. But perhaps relying on > this would be risky looking forward, so I guess we better don't make > assumptions here and instead flag mnemonics (in the templates) where > retrying may be necessary when no match was found during the 1st pass. This sounds reasonable. > FTAOD - I take it calling free() with a NULL argument is not a concern? We can use free (NULL). > I guess to prove (and going forward guarantee) the apparent behavior of > parse_insn() I'd like to constify its first parameter. This might > involve adding a cast (to drop const-ness again after the call), which > I generally would like to avoid, or some "interesting" pointer > arithmetic. If you have any opinion here up front, please let me know. Can we avoid it by adding some new entries to the opcode table? I don't think we need many such entries. -- H.J.