From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by sourceware.org (Postfix) with ESMTPS id 398F6385E82C; Mon, 16 Mar 2020 14:47:19 +0000 (GMT) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 3D0EDACA2; Mon, 16 Mar 2020 14:47:16 +0000 (UTC) Date: Mon, 16 Mar 2020 14:47:15 +0000 (UTC) From: Michael Matz To: =?UTF-8?Q?F=C4=81ng-ru=C3=AC_S=C3=B2ng?= cc: Ali Bahrami , binutils@sourceware.org, Rainer Orth , gnu-gabi , x86-64-abi@googlegroups.com Subject: Re: SHT_UNWIND instead of SHT_X86_64_UNWIND? (was: RFC: Usefulness of SHT_X86_64_UNWIND) In-Reply-To: <20200313223347.vvda5wduy3oiyx7u@google.com> Message-ID: References: <20200313180946.aegom4ekzhjrywgo@google.com> <4402d6f9-1804-9709-b276-17e8c2a5da17@Oracle.COM> <20200313223347.vvda5wduy3oiyx7u@google.com> User-Agent: Alpine 2.21 (LSU 202 2017-01-01) MIME-Version: 1.0 X-Spam-Status: No, score=-0.0 required=5.0 tests=KAM_DMARC_STATUS, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gnu-gabi@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gnu-gabi mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2020 14:47:20 -0000 Hello, On Fri, 13 Mar 2020, Fāng-ruì Sòng via Gnu-gabi wrote: > OK, so it is unfortunate that x86-64 psABI says "The call frame > information needed for unwinding the stack is output into one or more > ELF sections of type SHT_X86_64_UNWIND." while there is no corresponding > change made to the most widely assembler (GNU as). This sentence > triggered https://reviews.llvm.org/rL252300 which made clang integrated > assembler diverge. > > At this point, I agree that the world is not going to be simplified. > Toolchain has to continue to support SHT_X86_64_UNWIND. However, I think > clarifying the canonical section type can guide future assembly files > and toolchain support. I think realistically this is the only thing we can do for the x86-64 psABI: clarify and add acceptable section types, nothing of that will simplify anything. So, I'd add SHT_PROGBITS as an additional acceptable type for .eh_frame, but continue to recommend SHT_X86_64_UNWIND (because that's in spirit), linkers will have to continue accepting both types for the next umpteen years. So, that would document the de-facto state of the psABI with a little nudging towards a better future (the recommendation). Adding a whole new general section type (SHT_UNWIND) seems to accomplish nothing than additional code for all existing psABIs. For _future_ psABIs it might make sense to allocate and document an SHT_UNWIND now, but for existing ones it doesn't seem to make much sense. (And for the general type: would we then require this section type to be forever associated with dwarf unwind info? What about ARM unwind info, that couldn't use SHT_UNWIND then. Or would we leave the specific format of SHT_UNWIND to the psABI, but still allow them to use that common section type despite principal difference to other ABIs? All of those questions can be answered in multiple ways with pros and cons for each, but they need to be answered before a generic SHT_UNWIND could be introduced, at which point it's even less obvious if we should even bother) (FWIW, my personal opinion would be to document SHT_UNWIND in the gABI, with psABI to clarify content; but to _not_ make use of it in existing psABIs) Ciao, Michael. P.S: I wish there would have been more implementations of the x86-64 psABI right from the beginning ;-)