From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14352 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Fangrui Song Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] remove stray .end directives Date: Wed, 3 Jul 2019 10:21:19 +0800 Message-ID: <20190703022119.jerw3x43tyysbjyp@gmail.com> References: <20190702165841.GZ1506@brightrain.aerifal.cx> <20190702175353.GD22788@voyager> <20190702210323.GA1506@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="118276"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: NeoMutt/20180223-112-0c5bf3 Cc: musl@lists.openwall.com To: Rich Felker Original-X-From: musl-return-14368-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jul 03 04:21:39 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hiUtu-000UdG-CM for gllmg-musl@m.gmane.org; Wed, 03 Jul 2019 04:21:38 +0200 Original-Received: (qmail 5508 invoked by uid 550); 3 Jul 2019 02:21:35 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 5490 invoked from network); 3 Jul 2019 02:21:35 -0000 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:in-reply-to:user-agent; bh=CYIuYMSuL5ElQY1RvTCWtHRe5Dk7V1KONrEHY6apw8I=; b=tdoQIwg9VeiaWW9OGyv97rqzhkmmd++5EIlzH6lwhec5KZ/mEVcSVK2asic2N8EGO1 xtZ9k/p8GWmqF7vqtj6mjfHHp0nQZXzGb+9OfcL6k+v5VDbySgzjloBfCCjEkY4gjqj7 k9IaUfJirsQE8YkaT8RT1LbFid5zrljc/pdBW0g5walb9W+HalEu59XqMhAUT/jJLmJR 3t2U2JPwe8EIUyghkeff02IDoci1PXTHqVjGUsvP3dgajyqLUfgRrx21w8OdvdqY7Jl9 +Tgl600UiM3iAh/JuHpIFnwuw9WUNrP+0OSbfouw2sXokcSNlK3Mv+v8ZnsEQI5u+SKr 2ibQ== X-Gm-Message-State: APjAAAXJwhTIBFsBHgoCjPnzcVV7dLHNaFr5iODcpixJRoKrAYNgtC4R 6riCwcHRPH3NPC0QCKKi7oY= X-Google-Smtp-Source: APXvYqxP/Yq4BNphyx8Z2n8BykUxRvx0rbQMxsLae1QZx5nF9gfH3hDxtPVBK+zgR5UgCE1hGZeKfw== X-Received: by 2002:a17:902:1e7:: with SMTP id b94mr31063677plb.333.1562120483188; Tue, 02 Jul 2019 19:21:23 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20190702210323.GA1506@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:14352 Archived-At: On 2019-07-02, Rich Felker wrote: >On Tue, Jul 02, 2019 at 07:53:53PM +0200, Markus Wichmann wrote: >> On Tue, Jul 02, 2019 at 12:58:41PM -0400, Rich Felker wrote: >> > On Tue, Jul 02, 2019 at 01:09:46PM +0000, Song Fangrui wrote: >> > > diff --git a/src/ldso/powerpc64/dlsym.s b/src/ldso/powerpc64/dlsym.s >> > > index 7eb691d9..a14715fd 100644 >> > > --- a/src/ldso/powerpc64/dlsym.s >> > > +++ b/src/ldso/powerpc64/dlsym.s >> > > @@ -8,5 +8,4 @@ dlsym: >> > > .localentry dlsym,.-dlsym >> > > mflr 5 # The return address is arg3. >> > > b __dlsym >> > > - .end dlsym >> > > .size dlsym, .-dlsym >> > >> > This sounds right. Before I remove this, anyone have any idea what the >> > purpose of these was to begin with? >> > >> > Rich >> >> I can't tell you the purpose, but I can tell you the effect: This >> directive ends assembly parsing. Therefore the .size directive below >> them was never in effect before (if the documentation is to be trusted). >> Dunno if that has any apparent effect though (besides the output of >> objdump). >> >> The PPC64 file was added in one go by Bobby Bingham in 2016. I guess the >> line there is for consistency with PPC32. The PPC32 file was added in >> 2012 by rofl0r, though the blame also shows one Richard Pennington (not >> the log, though). Weird. Anyway, the log message is also not very >> enlightening. I can only assume the line was added in error. That, or >> the .size directive. Together they make no sense. > >Thanks. Applying. In linkers, I think st_size is only useful for STT_OBJECT (copy relocation). It is not really necessary for functions. There is some small value to have non-zero st_size for STT_FUNC though: symbolizers and some other binary inspection tools may leverage this field. Since most assembly files in musl do have .size, I think it makes sense to omit it for consistency.