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.133.124]) by sourceware.org (Postfix) with ESMTPS id 929063853550 for ; Fri, 30 Sep 2022 09:12:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 929063853550 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1664529156; 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=xnliX9cTTi1T2ZayFjXvF8iA6CGjnNVvXWxDne2fgSk=; b=fpzuemLz1ON4bLyLq3yPh3VG5MhOkBfC7TeywdgyXN5EADx7K1IQhVlcPkNpcCCYY79IlO j0L62IPmX9riJkZk0gFVNTmsOTqg0JsyhOhQ5mQWWwo0KmR6f972a0O+KAYixYhzQN/Z2a G470PlWn2la/jYtRHhzXJZGrcFa01Xc= Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-378-CnE-tz8SMV2-fdTfnaMnuQ-1; Fri, 30 Sep 2022 05:12:35 -0400 X-MC-Unique: CnE-tz8SMV2-fdTfnaMnuQ-1 Received: by mail-qt1-f200.google.com with SMTP id g6-20020ac84b66000000b0035cf832dec9so2553032qts.6 for ; Fri, 30 Sep 2022 02:12:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:subject:from:content-language :references:cc:to:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date; bh=xnliX9cTTi1T2ZayFjXvF8iA6CGjnNVvXWxDne2fgSk=; b=Z3EhZ36lLe5it6Di1clXHtVjPL7QtArZDq5DlAAeRDBO/mTDci/hPtYlmO1IIq3TA+ JBJ4rc4LVaqY+fUD7BPXR74NH6lMcV8dHdSIpxedeyPelsFpwVaSEmrmPJDKMgoO6IM4 TP2S0qdxvbCa1CmcLMsmMIkKWkRl27BZyluavF42V1HC6MJcZgWjgtIJ2eYBPeAPh2iQ oy8QNK45VdSiNJ7nV0nGx8Aie6pDjUbXrt80d0pKnSQb5RKNM/CkF+zB6aoAlNObVGjR W5H9VCzWL1bpojYHGfkyxss1tG1i9R1JrcAzFYwciKSfcdyTzO0anbTcfy3OBkphw92Z zZvg== X-Gm-Message-State: ACrzQf0nQbM+NU79uSP4+2YoYmsoec9ASPx3yBMngslS8FwgCz8iU7pM ftV/LE288VP3369DEge3lNPDhcWiQoh+MYGG+yKCoiz8flI9QnqSXHozFbTttUxLKUWzTrCFtW9 8jHaGLGP4xQLEpZVo0A== X-Received: by 2002:a05:622a:5a9b:b0:35b:b219:99d7 with SMTP id fz27-20020a05622a5a9b00b0035bb21999d7mr5745052qtb.510.1664529154521; Fri, 30 Sep 2022 02:12:34 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6DOfAZk48NLBRVLd6Rucgl6/65YdI54/VCTc4DcPosiLNDx+TFDU6MaR8x5Y5CzzvMORngeg== X-Received: by 2002:a05:622a:5a9b:b0:35b:b219:99d7 with SMTP id fz27-20020a05622a5a9b00b0035bb21999d7mr5745043qtb.510.1664529154323; Fri, 30 Sep 2022 02:12:34 -0700 (PDT) Received: from [192.168.1.18] ([79.123.82.157]) by smtp.gmail.com with ESMTPSA id r4-20020a05620a298400b006ce5f4720cdsm2150888qkp.47.2022.09.30.02.12.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 30 Sep 2022 02:12:33 -0700 (PDT) Message-ID: <735c9acd-7ccb-2b84-8952-8ef106aa9057@redhat.com> Date: Fri, 30 Sep 2022 10:12:31 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.0 To: Indu Bhagat , binutils@sourceware.org Cc: weimin.pan@oracle.com References: <20220930000440.1672106-1-indu.bhagat@oracle.com> From: Nick Clifton Subject: Re: [PATCH,V1 00/14] Definition and support for SFrame unwind format In-Reply-To: <20220930000440.1672106-1-indu.bhagat@oracle.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-GB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,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: Hi Indu, > The format specification document still mains a TODO at this time. I plan to > resume working on this after I have tackled the task of SFrame generation for > PLT/veneers in aarch64. I am concerned about this. If you do not have a specification then it is going to be hard to get the format adopted by third parties. I assume that you would like tools such as LLVM to support the format, as well as projects like the Linux kernel. Maybe other commercial interests or academic endeavours. None of them are going to take the format seriously if there isn't a specification. > The format is supported on AMD64 and AARCH64 ABIs only. This is sad and a little bit surprising. I would have at least expected to see the x86_64 architecture listed as well, and ideally I would like to see a whole lot more. I do hope that your plans including writing a "How to extended the SFrame specification/implementation to support a new architecture" document. > The information stored > in the .sframe section is a subset of what .eh_frame can convey: .eh_frame can > convey how to resurrect all callee-saved registers, if need be; but .sframe > does not. Is it possible to convert existing .eh_frame sections into equivalent .sframe sections ? Cheers Nick