From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) by sourceware.org (Postfix) with ESMTPS id B95B33858C52 for ; Mon, 12 Feb 2024 22:25:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B95B33858C52 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=obs.cr Authentication-Results: sourceware.org; spf=none smtp.mailfrom=obs.cr ARC-Filter: OpenARC Filter v1.0.0 sourceware.org B95B33858C52 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::f2f ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707776749; cv=none; b=IOve+DxFODHlBsj7Gjho3s+rvUwuQHTUEACprmln40n2w6lyQ17oLXv85FPWPnkkCqFovNjjaSqq7NCY4c7Pr4kW08DXiWl5pUhZT/9jycSnQFPnrD/HRS1wxVRAxXlbN1/FDtJCcbspSICVTfbGfW+0akopn8vb54d99qr4ptU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707776749; c=relaxed/simple; bh=5FBt/w7NMzLH4ivr0t9cLp5aKpT2EdzeOWPbq2qTyRc=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=YJ5d+sYfjML7cr2+3ycRkKdJIS8HaO/8SFm1WZNjkBiLr3tp4VsWDGDQeV3cwAbl1CtPvjMGAwz09vnhcZ+uIVDzN/chjBvIK9v6aqYaOsZwStQoZg2iJj3Dc43zfsyu6X/6AMEcqUgSTITU818mmYllqvNelWHaJrpQEEQRP3k= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-qv1-xf2f.google.com with SMTP id 6a1803df08f44-68cc9061c78so20090836d6.3 for ; Mon, 12 Feb 2024 14:25:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=obs-cr.20230601.gappssmtp.com; s=20230601; t=1707776745; x=1708381545; darn=sourceware.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=JIxGIA/nSCXJFV0LaXk7tks7bMqEdZuGLD1uKFXn6iU=; b=de2ZPFi9fdxOL05bdjJPUne5lOjmn880liRkmWRGW1TPeHaVf+lZijTJ66gQ6jC93j mnT/EGOPsgZ4ALPVATV6gAJX+s+rwLGoEK9siUf7Aqm0m89Cek9PWLCd/oo6A1E4TPRr 2eo/wFg3JS5SDAPFfZ3YdKX8/MX6J/nyIDAMR0ePji1kLN267/B3cZUrunO9fp8KNtIv ZoyX/wP3rJsNav22SqtLPod/utyI+YE37AOhrCOi7ZZ5cfmYCyUtnLPqNRvXjc5dAEBt UAD+n3GpHBTu/lHTw3chnr12bvkj12dfimRLRoBtOvUS3XShDyo6aSwz3/1UIlJ+xaf7 W20g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707776745; x=1708381545; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=JIxGIA/nSCXJFV0LaXk7tks7bMqEdZuGLD1uKFXn6iU=; b=RB6687JjZ7ntq3IzgK/55EpyI1N1wpyjrkP4rinBFDEqv/Ykw+ho7CQv66mVncqt9R teQfpQh5ucaLvC9zEYYU019hGjMFWw+Dh87fnHhUv4YmHiV8KcLjtX3ip4P21zwZv+Mc sasxAr/Bzs5N6R2myluG5LZMu8HJfzqjW0uQ2AwHsM/dpx1qXR14M1hJ6rL2DknpErnk ju+UOrbBYaf8K91BA+MgWvhFw9GOJkXvCBpJe/gGJC8WEM0OFLC9Ns4Zw1Jy8Y+mMzYQ omV6PclV64PyOxONdqPWDHRvIIoGSDYVYPETzCj6V8bp12AZssmIzC2wraZb03X+M07h oeQw== X-Gm-Message-State: AOJu0YxRk8O5GAsfQtRFlqA6u2YiW499PRHN4GSdSitFxiIGSjBdr6Dg J5/3/bvgOkUtlXTIWBl0uG3yqoLC9sIt8g5vtmuoCfXA32XQvrstgsiAjhxrwpETW11kar7ick2 l2UlrJ6aS0hjE7UeU4mCUpebsIUD9M9tFrDP9Vg== X-Google-Smtp-Source: AGHT+IFlBKGgBziNCYWYCjBkHVk7fUa5oK4ib7gXeFCcx2BavBurmMenIvT/NkWydsVgWbOPWDnO6qtCxv6UNL943hk= X-Received: by 2002:a05:6214:d45:b0:68c:c37a:a274 with SMTP id 5-20020a0562140d4500b0068cc37aa274mr11960765qvr.3.1707776745085; Mon, 12 Feb 2024 14:25:45 -0800 (PST) MIME-Version: 1.0 References: <20240212174209.620310-1-hawkinsw@obs.cr> <87h6idv86g.fsf@oracle.com> In-Reply-To: <87h6idv86g.fsf@oracle.com> From: Will Hawkins Date: Mon, 12 Feb 2024 17:25:34 -0500 Message-ID: Subject: Re: [PATCH v2 0/1] Add BPF callx support to objdump and as To: "Jose E. Marchesi" , Dave Thaler Cc: binutils@sourceware.org, Yonghong Song , Eduard Zingerman Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_NONE,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: Hello! First, thank you for the response! On Mon, Feb 12, 2024 at 1:39=E2=80=AFPM Jose E. Marchesi wrote: > > > Hi Will. > > [Adding Yonghong and Eduard in CC] > > > After additional consideration and discussion with Jose and Dave, > > it seems like we have determined the way that clang, gcc and binutils > > need to handle the callx/callr: > > > > 1. callr remains with the register holding the target of the jump store= d > > in the dst_reg. > > 2. callx is added with the register holding the target of the jump stor= ed > > in the imm32. > > 3. We have to remove the pseudoc syntax because it is no longer possibl= e > > to disambiguate between versions of call by simply looking at the > > parameter. > > I don't recall reaching any agreement on the above. What is the point > of having both callr and callx? Sorry! I was being slightly loose in terms of agreement -- I was reading into your comments in the email between you, me and Dave from earlier this weekend! The only point in having both callr and callx was to allow the gcc encoding to continue to exist in its current form. I assumed that there was a compelling reason and certainly did not want to do anything to interfere with the great work that you are doing! > > The existing callr is generated by GCC in -mxbpf mode. It is an > experimental extension that we use in order to be able to run more of > the GCC testsuite, so it is always possible to change it to use imm32 > instead of dst_reg. > > I wouldn't personally welcome that change and would much prefer if clang > starts using either reg_src or reg_dst, because compromising/reserving > endian-dependent 32 whole bits for a register number that only requires > 4 bits seems like a waste of insn space that will complicate future ISA > extensions. I 100% agree that it is less than ideal. However, it seems like the cat is out of the bag. I am adding Dave who is leading the ISA standardization effort. He and I (and others) have discussed this as recently as this morning. I will let him weigh in on whether or not we have the "power" to push back on clang's choice of how to encode the instructions. > > In either case, if we all use the same encoding for the indirect call > instruction (I fail to see any reason for not doing so) then point > 3. becomes moot. I agree and I really would like that to be the outcome. However, see above (insert smiley face here!) Thank you for responding! Will > > > > > Tests are added/refactored to meet the above. > > > > I am more than happy to resend as a separate mailing to the list but > > sending first as a reply in order to keep list traffic manageable. > > > > As I said before, I sincerely appreciate all that you are doing for > > the community and how welcoming you have been to a first-time contribut= or. > > > > Sincerely, > > Will > > > > Will Hawkins (1): > > objdump, as: Add callx support for BPF CPU v1 > > > > gas/config/tc-bpf.c | 25 ++++++++++++++++++- > > gas/testsuite/gas/bpf/bpf.exp | 4 +-- > > .../gas/bpf/{indcall-1.d =3D> callr.d} | 4 +-- > > .../gas/bpf/{indcall-1.s =3D> callr.s} | 2 +- > > gas/testsuite/gas/bpf/indcall-1-pseudoc.d | 23 ----------------- > > gas/testsuite/gas/bpf/indcall-1-pseudoc.s | 13 ---------- > > include/opcode/bpf.h | 3 ++- > > opcodes/bpf-dis.c | 6 +++++ > > opcodes/bpf-opc.c | 4 ++- > > sim/bpf/bpf-sim.c | 4 +++ > > 10 files changed, 44 insertions(+), 44 deletions(-) > > rename gas/testsuite/gas/bpf/{indcall-1.d =3D> callr.d} (90%) > > rename gas/testsuite/gas/bpf/{indcall-1.s =3D> callr.s} (90%) > > delete mode 100644 gas/testsuite/gas/bpf/indcall-1-pseudoc.d > > delete mode 100644 gas/testsuite/gas/bpf/indcall-1-pseudoc.s