From: Fangrui Song <maskray@google.com>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: Alan Modra <amodra@gmail.com>,
Nick Desaulniers <ndesaulniers@google.com>,
clang-built-linux@googlegroups.com, Joel Stanley <joel@jms.id.au>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v2] powerpc/boot: Delete unneeded .globl _zimage_start
Date: Thu, 26 Mar 2020 15:26:12 -0700 [thread overview]
Message-ID: <20200326222612.zbbiyi75emq6npzn@google.com> (raw)
In-Reply-To: <20200326221625.GA22482@gate.crashing.org>
On 2020-03-26, Segher Boessenkool wrote:
>On Wed, Mar 25, 2020 at 09:42:57AM -0700, Fangrui Song wrote:
>> .globl sets the symbol binding to STB_GLOBAL while .weak sets the
>> binding to STB_WEAK. GNU as let .weak override .globl since binutils-gdb
>> 5ca547dc2399a0a5d9f20626d4bf5547c3ccfddd (1996). Clang integrated
>> assembler let the last win but it may error in the future.
>
>GNU AS works for more than just ELF. The way the assembler language
>is defined, it is not .weak overriding .globl -- instead, .weak sets a
>symbol attribute. On an existing symbol (but it creates on if there is
>none yet).
>
>Clang is buggy if it does not allow valid (and perfectly normal)
>assembler code like this.
https://sourceware.org/pipermail/binutils/2020-March/110399.html
Alan: "I think it is completely fine for you to make the llvm assembler
error on inconsistent binding, or the last directive win. Either of
those behaviours is logical and good, but you quite possibly will run
into a need to fix more user assembly.
I am doing some experiments whether making clang integrated assembler
error is feasible.
next prev parent reply other threads:[~2020-03-26 22:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-25 16:42 [PATCH v2] powerpc/boot: Delete unneeded .globl _zimage_start Fangrui Song
2020-03-26 22:16 ` Segher Boessenkool
2020-03-26 22:26 ` Fangrui Song [this message]
2020-03-27 15:24 ` Segher Boessenkool
2020-03-27 16:50 ` Fangrui Song
2020-03-27 18:27 ` Segher Boessenkool
2020-04-01 12:53 ` Michael Ellerman
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=20200326222612.zbbiyi75emq6npzn@google.com \
--to=maskray@google.com \
--cc=amodra@gmail.com \
--cc=clang-built-linux@googlegroups.com \
--cc=joel@jms.id.au \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=ndesaulniers@google.com \
--cc=segher@kernel.crashing.org \
/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.
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).