From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) by sourceware.org (Postfix) with ESMTPS id 8472639450C7; Fri, 13 Mar 2020 23:15:17 +0000 (GMT) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 02DN9XoS139522; Fri, 13 Mar 2020 23:15:12 GMT Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2120.oracle.com with ESMTP id 2yqtavp45t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 13 Mar 2020 23:15:12 +0000 Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 02DN8A59142725; Fri, 13 Mar 2020 23:15:11 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3020.oracle.com with ESMTP id 2yreujqxfj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 13 Mar 2020 23:15:11 +0000 Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 02DNF3rM016544; Fri, 13 Mar 2020 23:15:03 GMT Received: from [10.154.193.100] (/10.154.193.100) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 13 Mar 2020 16:15:02 -0700 Subject: Re: SHT_UNWIND instead of SHT_X86_64_UNWIND? To: =?UTF-8?B?RsSBbmctcnXDrCBTw7JuZw==?= Cc: x86-64-abi@googlegroups.com, Rainer Orth , gnu-gabi , binutils@sourceware.org References: <20200313180946.aegom4ekzhjrywgo@google.com> <4402d6f9-1804-9709-b276-17e8c2a5da17@Oracle.COM> <20200313223347.vvda5wduy3oiyx7u@google.com> From: Ali Bahrami Message-ID: Date: Fri, 13 Mar 2020 17:15:01 -0600 User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <20200313223347.vvda5wduy3oiyx7u@google.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9559 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 suspectscore=0 bulkscore=0 mlxlogscore=999 adultscore=0 spamscore=0 mlxscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2003130102 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9559 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 suspectscore=0 phishscore=0 priorityscore=1501 clxscore=1011 mlxscore=0 adultscore=0 spamscore=0 bulkscore=0 mlxlogscore=999 lowpriorityscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2003130102 X-Spam-Status: No, score=-0.2 required=5.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_PASS, 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 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: Fri, 13 Mar 2020 23:15:18 -0000 On 3/13/20 4:33 PM, Fāng-ruì Sòng wrote: > 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. If the linkers have to support both, then I don't see much to clarify. Either use is acceptable, and generates identical valid objects. > Now we have two choices for the canonical and recommended section type (SHT_PROGBITS should still be supported) > > a) SHT_UNWIND > >   We need a definition `#define SHT_UNWIND 0x70000001` in binutils and glibc/elf/elf.h It can't be 0x70000001, because that number comes from the platform specific range between SHT_LOPROC-SHT_HIPROC. A generic SHT_UNWIND should be allocated from an unused value in the generic ABI range (below SHT_LOOS). However, doing that means having to add a lot of new code to support this new value and interpret it as an unwind section, layered on top of the existing support for PROGBITS, and X86_64_UNWIND. It would have been nice if we had started with SHT_UNWIND, but it doesn't really seem worth it now. > b) SHT_PROGBITS > >   https://urldefense.com/v3/__https://reviews.llvm.org/D76151__;!!GqivPVa7Brio!M8bMtH5y6OK--fuc9QIXqdkgXf262XGmGGfEd8HQIP5Ik7SOHjp0JvJan5ERENGQ$   Unfortunately this does not follow the ELF spirit. I won't object to >   it if a) is excluded. Modern Solaris doesn't really care whether you tag these as UNWIND, or PROGBITS. It throws both into the same section. The resulting output section from our ld will be tagged UNWIND on x86_64, and PROGBITS on other platforms, as has been the case for years. > "gcc produces UNWIND" - I think you meant SHT_PROGBITS. In the GCC > repository, libphobos/libdruntime/core/sys/solaris/sys/elf_amd64.d is > the only place where SHT_X86_64_UNWIND is mentioned. I stand corrected. I just tried it on a Linux box, and it is PROGBITS. On Solaris, gcc still sets it to UNWIND, I think probably to avoid breaking us. Frankly, I like seeing these tagged as UNWIND, since I believe in not overloading PROGBITS, but it's just a personal taste, not something others need to care about. > https://urldefense.com/v3/__https://reviews.llvm.org/rL291107__;!!GqivPVa7Brio!M8bMtH5y6OK--fuc9QIXqdkgXf262XGmGGfEd8HQIP5Ik7SOHjp0JvJan3IcUwjF$ As to section flags, at the very least SHF_GROUP and SHF_COMPRESSED should be ignored. > SHF_MERGE may be ignored as well. UNWIND sections are SHF_ALLOC, and SHF_COMPRESSED cannot be applied to allocable sections, so I think you should throw a "bad object" error, rather than ignore, so that the producing program can be caught and fixed. MERGE is a hint, the meaning of which depends on the section type. I don't think it has a defined meaning for unwind, so the normal behavior is to ignore it. As to GROUP, it depends on the type of output object. For a final object, group processing occurs before the output object is created, and at that point, the GROUP flags should have been removed. If you're producing a relocatable output object though, you'd want to preserve the groups, and have multiple sections. >> Solaris 10 (ancient) isn't. Do you know Rainer Orth (cc;d)? >> I'll suggest that you contact him offline and discuss it. Feel free >> to cc me, and thanks. > > I don't:) So it looks like https://urldefense.com/v3/__https://github.com/libffi/libffi/pull/546__;!!GqivPVa7Brio!M8bMtH5y6OK--fuc9QIXqdkgXf262XGmGGfEd8HQIP5Ik7SOHjp0JvJanz-YOFPB$  can be further simplified by deleting SHF_WRITE support completely. Don't let that stop you, he's very friendly. :-) Rainer is the one person who knows where all the gcc-on-Solaris bodies are buried, and can advise on things like this. He and I work together all the time on gcc support, and he's also got an interest in Clang, so if you're working with him, I'll probably get pulled in as needed. - Ali