From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) by sourceware.org (Postfix) with ESMTPS id 409BB3861C56 for ; Mon, 16 Mar 2020 18:51:05 +0000 (GMT) Received: by mail-pj1-x102c.google.com with SMTP id l36so8817189pjb.3 for ; Mon, 16 Mar 2020 11:51:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=PYenSY81B05XkuCQZLkV4vUP6EesLqjfT4vjYcBMnto=; b=ACEB3wDZ3Z92JckfzXYtPNb1+nrDKahnoijLgbOVkOKANSqevwiq1Bh6nhuW9Iwfvh H3TMmRT28L1x4kfshE/dDRwl35Zo/AvMmGC8Fg0EIq47uBUOw4okUoLrAbqVn9kTZqUY K/V9mvgWvd8FHURsX4ebBiWSrzF7HrN+vJUak8AsNw1tMxKNNdrSYhxKcxNW81OdZdKB hf32ghGLkiBZsMLR7h37PYApDaNCpkii8SsTqI7PdzCfnFL11AHbF1yydfT2MyJzFFG7 OJL6Mb5UH4K6AOn9shKpFyOeOggXq1swDZORVJr2kR0rYOds3i7Hm+LzPeSL9Iyqniwz alcw== X-Gm-Message-State: ANhLgQ100X5wMtwq9oM2PdPf/0nGhjWp2mmcbJ/oTUrG11q2FCvMVhCQ HmdMoT5Sjdt6+e6ji9g7DpVpxw== X-Google-Smtp-Source: ADFU+vvqHSjPVo4QIcT+PGF4Cvmw71B2Msw7Jnp49QpcnL14E4pxcgKtRpUVGHDDqoqlQ+Dc18tXAQ== X-Received: by 2002:a17:902:464:: with SMTP id 91mr525239ple.261.1584384664095; Mon, 16 Mar 2020 11:51:04 -0700 (PDT) Received: from google.com ([2620:15c:2ce:0:9efe:9f1:9267:2b27]) by smtp.gmail.com with ESMTPSA id l26sm604691pff.136.2020.03.16.11.51.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Mar 2020 11:51:03 -0700 (PDT) Date: Mon, 16 Mar 2020 11:51:00 -0700 From: =?utf-8?B?RsSBbmctcnXDrCBTw7JuZw==?= To: Michael Matz 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) Message-ID: <20200316185100.ggw6agfui7xtwqn6@google.com> References: <20200313180946.aegom4ekzhjrywgo@google.com> <4402d6f9-1804-9709-b276-17e8c2a5da17@Oracle.COM> <20200313223347.vvda5wduy3oiyx7u@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-15.5 required=5.0 tests=DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, FSL_HELO_FAKE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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 18:51:06 -0000 On 2020-03-16, Michael Matz wrote: >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). +1 for clarifying that SHT_PROBITS .eh_frame is acceptable. SHT_X86_64_UNWIND is still the recommended type. I'll update my https://reviews.llvm.org/D76151 accordingly to allow .section .eh_frame,"a",@progbits (canonical one is @unwind) To GNU as maintainers, should @unwind be accepted for non-x86? >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) +1 Clarifying in gABI that 0x70000001 (processor specific) could not be used for unrelated purposes would be nice... Sadly Xinuos (formerly SCO) stopped maintaing the website a few years ago.. >Ciao, >Michael. >P.S: I wish there would have been more implementations of the x86-64 psABI >right from the beginning ;-)