From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 31301 invoked from network); 9 Nov 2022 11:49:10 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 9 Nov 2022 11:49:10 -0000 Received: (qmail 20362 invoked by uid 550); 9 Nov 2022 11:49:07 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 20330 invoked from network); 9 Nov 2022 11:49:06 -0000 Date: Wed, 9 Nov 2022 12:48:54 +0100 From: Szabolcs Nagy To: =?utf-8?B?546L5rSq5Lqu?= Cc: musl@lists.openwall.com Message-ID: <20221109114854.GD98588@port70.net> Mail-Followup-To: =?utf-8?B?546L5rSq5Lqu?= , musl@lists.openwall.com References: <66e5839c-0be7-2c29-df5f-713d7e0d758e@loongson.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <66e5839c-0be7-2c29-df5f-713d7e0d758e@loongson.cn> Subject: Re: [musl] A question about if crti.s and crtn.s is not necessary? * =E7=8E=8B=E6=B4=AA=E4=BA=AE [2022-11-09 10:51= :37 +0800]: > In LoongArch port, I found build musl and libc-test is OK without > crt/loongarch64/crti.s and crt/loongarch64/crtn.s, >=20 > so I want to ask if crti.s and crtn.s is not necessary in architecture? in musl the generic crti/crtn.o is empty. which works if no user code uses .init or .fini sections. the old way of doing ctors/dtors used .init/.fini but new targets use =2Einit_array/.fini_array for a while now. if no language feature uses .init/.fini, should we support this? well if they are still part of the elf abi and somebody writes code manually for .init/.fini then yes. however it's not clear to me that default linker scripts that still treat these sections specially on new targets do so as old habit i.e. they have no abi relevance, or if this is still something that's supposed to work. i think they can be empty on new targets, but it does not hurt to have support in case somebody needs the .init/.fini behaviour (which has static and dynamic linker support already anyway). libc-test does not test for it, and would be tricky to do so portably.