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=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 16600 invoked from network); 18 Sep 2020 08:10:21 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 18 Sep 2020 08:10:21 -0000 Received: (qmail 20028 invoked by uid 550); 18 Sep 2020 08:10:16 -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 20010 invoked from network); 18 Sep 2020 08:10:16 -0000 Date: Fri, 18 Sep 2020 10:10:04 +0200 From: Szabolcs Nagy To: Rich Felker Cc: sidneym@codeaurora.org, musl@lists.openwall.com Message-ID: <20200918081004.GG2947641@port70.net> Mail-Followup-To: Rich Felker , sidneym@codeaurora.org, musl@lists.openwall.com References: <096001d64684$d322d0f0$796872d0$@codeaurora.org> <20200619224624.GO6430@brightrain.aerifal.cx> <0a7201d646aa$921b84f0$b6528ed0$@codeaurora.org> <20200620032032.GR6430@brightrain.aerifal.cx> <078f01d65edc$80e892f0$82b9b8d0$@codeaurora.org> <20200723215603.GA755469@port70.net> <110801d68c6a$dfe3f950$9fabebf0$@codeaurora.org> <20200917013236.GV3265@brightrain.aerifal.cx> <073501d68d42$4a8c6080$dfa52180$@codeaurora.org> <20200918010806.GX3265@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200918010806.GX3265@brightrain.aerifal.cx> Subject: Re: [musl] Hexagon DSP support * Rich Felker [2020-09-17 21:08:07 -0400]: > On Thu, Sep 17, 2020 at 05:31:29PM -0500, sidneym@codeaurora.org wrote: > > > -----Original Message----- > > > From: 'Rich Felker' > > > Sent: Wednesday, September 16, 2020 8:33 PM > > > To: musl@lists.openwall.com > > > Subject: Re: [musl] Hexagon DSP support > > > > > > On Wed, Sep 16, 2020 at 03:49:28PM -0500, sidneym@codeaurora.org wrote: > > > > > > > > +__asm__( > > > > +".section \".note.ABI-tag\", \"a\" \n" > > > > +".align 4 \n" > > > > +".long 1f - 0f /* name length */ \n" > > > > +".long 3f - 2f /* data length */ \n" > > > > +".long 1 /* note type */ \n" > > > > +"0: .asciz \"GNU\" /* vendor name seems like this should be > > MUSL but > > > lldb doesn't agree.*/ \n" > > > > +"1: .align 4 \n" > > > > +"2: .long 0 /* linux */ \n" > > > > +" .long 3,0,0 \n" > > > > +"3: .align 4 \n" > > > > +); > > > > > > Is there a reason this needs to be here at all? Shouldn't the tooling > > generate > > > it if it's actually wanted/needed? > > > > OK, this is here so lldb can select the right target allowing the same > > version of lldb to work in multiple runtime environments. I need to take a > > look at what the options are if this isn't a good place for this. > > OK, please follow up with what you find. I'm pretty sure this belongs > in the tooling though (as something the compiler emits or the > assembler emits based on how it's invoked and what its target is) not > in a file in libc. that gnu abi note specifies the minimum supported kernel version (linux 3.0.0 in this case) and in glibc it is explicitly added to all glibc dsos and to *crt1.o (so it depends on the libc not other tooling). i don't think the debugger should need this unless there was some linux abi change, in glibc it is used to check against the runtime kernel version and abort (or fail dlopen) if that is too old, but musl has no such logic. see comments about abi note in: https://sourceware.org/git?p=glibc.git;a=blob;f=csu/abi-note.c https://sourceware.org/git?p=glibc.git;a=blob;f=abi-tags see how it is used in dlopen: https://sourceware.org/git?p=glibc.git;a=blob;f=elf/dl-load.c;h=646c5dca40efcc9ba9f39dbda8b189864792216d;hb=HEAD#l1819