mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Fangrui Song <i@maskray.me>
To: Rich Felker <dalias@libc.org>
Cc: musl@lists.openwall.com
Subject: Re: [PATCH] remove stray .end directives
Date: Wed, 3 Jul 2019 10:21:19 +0800	[thread overview]
Message-ID: <20190703022119.jerw3x43tyysbjyp@gmail.com> (raw)
In-Reply-To: <20190702210323.GA1506@brightrain.aerifal.cx>

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.


      reply	other threads:[~2019-07-03  2:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-02 13:09 Song Fangrui
2019-07-02 16:58 ` Rich Felker
2019-07-02 17:53   ` Markus Wichmann
2019-07-02 21:03     ` Rich Felker
2019-07-03  2:21       ` Fangrui Song [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190703022119.jerw3x43tyysbjyp@gmail.com \
    --to=i@maskray.me \
    --cc=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).