[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 9 Nov 2022 12:48:54 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: 王洪亮 <wanghongliang@...ngson.cn>
Cc: musl@...ts.openwall.com
Subject: Re: A question about if crti.s and crtn.s is not necessary?
* 王洪亮 <wanghongliang@...ngson.cn> [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,
>
> 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
.init_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.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
