From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7941 Path: news.gmane.org!not-for-mail From: Alex Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH v8] Build process uses script to add CFI directives to x86 asm Date: Mon, 15 Jun 2015 08:42:47 +0200 Message-ID: References: <1433493558-9027-1-git-send-email-alexinbeijing@gmail.com> <20150614043725.GL17573@brightrain.aerifal.cx> <20150615032653.GB1173@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113ed5ec0f7a93051888c4bf X-Trace: ger.gmane.org 1434350584 26091 80.91.229.3 (15 Jun 2015 06:43:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 15 Jun 2015 06:43:04 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7954-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jun 15 08:43:04 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Z4O6o-00011E-LH for gllmg-musl@m.gmane.org; Mon, 15 Jun 2015 08:43:02 +0200 Original-Received: (qmail 11408 invoked by uid 550); 15 Jun 2015 06:43:00 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 11389 invoked from network); 15 Jun 2015 06:42:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=bw49w929olN1j0ctRD+pg78ggXuzhJ8WH1SbiEMwg9w=; b=WCmkSbA1jSDS187Jee48a2ZDFAqdZxN0CU+zrCH9+nk1ed/PUVlsDLY5oa/Jjvfwep 3voEWYKu3se9CLrncInEoeoSaPMVvdN3I406qvZgI3CQy9vZMQDfZ3hUQu7wWdo/SKAo Bv5MarfiMlx801FpU8c0JgThnMNz/ehoNlzrVc9Yv9lqAPvTJRt9pOCokVpGel7lbW4F xOi5y1pDWjLxv0paMUcWDTtMWs/kPGm84SEK47zQ/qhC8D4/evT3LANhv1+TawBJWRSw mdf+acTGg4i5QmWto9Z8hJsGNuEZV+8uJ/ifQs+8KoE1CNwYXDp8PsNQQeHkzHjbpubH MG/g== X-Received: by 10.107.15.40 with SMTP id x40mr2446980ioi.0.1434350567519; Sun, 14 Jun 2015 23:42:47 -0700 (PDT) In-Reply-To: <20150615032653.GB1173@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:7941 Archived-At: --001a113ed5ec0f7a93051888c4bf Content-Type: text/plain; charset=UTF-8 On Mon, Jun 15, 2015 at 5:26 AM, Rich Felker wrote: > On Sun, Jun 14, 2015 at 09:06:16PM +0200, Alex wrote: > > Thanks for the reply! Comments below: > > > > On Sun, Jun 14, 2015 at 6:37 AM, Rich Felker wrote: > > > > > On Fri, Jun 05, 2015 at 10:39:18AM +0200, Alex Dowad wrote: > > > > diff --git a/Makefile b/Makefile > > > > index 2eb7b30..9b55fd8 100644 > > > > --- a/Makefile > > > > +++ b/Makefile > > > > @@ -120,7 +120,11 @@ $(foreach s,$(wildcard > src/*/$(ARCH)*/*.s),$(eval > > > $(call mkasmdep,$(s)))) > > > > $(CC) $(CFLAGS_ALL_STATIC) -c -o $@ $(dir $<)$(shell cat $<) > > > > > > > > %.o: $(ARCH)/%.s > > > > - $(CC) $(CFLAGS_ALL_STATIC) -c -o $@ $< > > > > +ifeq ($(ADD_CFI),yes) > > > > + LC_ALL=C awk -f tools/add-cfi.$(ARCH).awk $< | $(CC) > $(ASFLAGS) -x > > > assembler -c -o $@ - > > > > +else > > > > + $(CC) $(ASFLAGS) -c -o $@ $< > > > > +endif > > > > > > Removing $(CFLAGS_STATIC_ALL) here is a regression. -Wa,--noexecstack > > > is necessary to prevent the kernel from giving us an executable stack > > > when asm files are linked. We could move it to a separate ASFLAGS, but > > > the patch doesn't do this, and unless there's a real need to avoid > > > passing CFLAGS, I'd rather not add more vars. (In this case, needing > > > the new var would be a silent security regression for anyone building > > > without re-running configure.) > > > > > > > The reason for not passing CFLAGS is because clang chokes on "-g" when > > assembling code with CFI directives. I also thought that ASFLAGS might > be a > > useful customization point for people who want to edit config.mak to > create > > a custom build. But you are the judge of that. > > > > Since it seems that CFLAGS is needed, would it be acceptable to bypass > the > > issue by saying that clang users simply won't be able to do debug builds > of > > musl until their compiler is fixed? The current state of LLVM's CFI > > generation is so bad that debug builds probably won't be useful anyways. > > Could you elaborate on what happens? I'm not opposed to this approach > as long as either (1) the configure test successfully determines that > CFI gen doesn't work on clang, or (2) the 'choking' just produces bad > CFI, but doesn't break the build. > The assembler errors out and doesn't produce any output. I have made the test in ./configure more robust now, to work around this problem. Insertion of .cfi directives will not occur when building with clang, until it is fixed. > > If that is a sticking point, I might put together a patch for LLVM and > see > > if they want it. Unfortunately, I have already discovered a bunch of > other > > problems with LLVM which would be nice to fix, but time for developing > and > > polishing patches is limited... > > Why is -g even being processes for asm? Are they trying to > auto-generate CFI when it's not present? I think this really needs to > be fixed in any case since there are plenty of .s files that _do_ have > CFI and build systems that use -g. All this points to clang's internal > assembler being not-widely-tested and not ready for serious use... :( > GAS silently disables auto-generation of debug info as soon as it sees an explicit debug directive. Clang gets ornery, digs its heels in, and says: "forget it, you aren't getting nothing from me if you tell me to generate debug info but then provide your own". Posting v9 patch now. --001a113ed5ec0f7a93051888c4bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jun 15, 2015 at 5:26 AM, Rich Felker <dalias@libc.org> wrote:
On Sun, Jun 14, 2015 at 09:06:16PM +0200, Alex wrote:
> Thanks for the reply! Comments below:
>
> On Sun, Jun 14, 2015 at 6:37 AM, Rich Felker <dalias@libc.org> wrote:
>
> > On Fri, Jun 05, 2015 at 10:39:18AM +0200, Alex Dowad wrote:
> > > diff --git a/Makefile b/Makefile
> > > index 2eb7b30..9b55fd8 100644
> > > --- a/Makefile
> > > +++ b/Makefile
> > > @@ -120,7 +120,11 @@ $(foreach s,$(wildcard src/*/$(ARCH)*/*= .s),$(eval
> > $(call mkasmdep,$(s))))
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0$(CC) $(CFLAGS_ALL_STATIC) -c -o $= @ $(dir $<)$(shell cat $<)
> > >
> > >=C2=A0 %.o: $(ARCH)/%.s
> > > -=C2=A0 =C2=A0 =C2=A0$(CC) $(CFLAGS_ALL_STATIC) -c -o $@ $&l= t;
> > > +ifeq ($(ADD_CFI),yes)
> > > +=C2=A0 =C2=A0 =C2=A0LC_ALL=3DC awk -f tools/add-cfi.$(ARCH)= .awk $< | $(CC) $(ASFLAGS) -x
> > assembler -c -o $@ -
> > > +else
> > > +=C2=A0 =C2=A0 =C2=A0$(CC) $(ASFLAGS) -c -o $@ $<
> > > +endif
> >
> > Removing $(CFLAGS_STATIC_ALL) here is a regression. -Wa,--noexecs= tack
> > is necessary to prevent the kernel from giving us an executable s= tack
> > when asm files are linked. We could move it to a separate ASFLAGS= , but
> > the patch doesn't do this, and unless there's a real need= to avoid
> > passing CFLAGS, I'd rather not add more vars. (In this case, = needing
> > the new var would be a silent security regression for anyone buil= ding
> > without re-running configure.)
> >
>
> The reason for not passing CFLAGS is because clang chokes on "-g&= quot; when
> assembling code with CFI directives. I also thought that ASFLAGS might= be a
> useful customization point for people who want to edit config.mak to c= reate
> a custom build. But you are the judge of that.
>
> Since it seems that CFLAGS is needed, would it be acceptable to bypass= the
> issue by saying that clang users simply won't be able to do debug = builds of
> musl until their compiler is fixed? The current state of LLVM's CF= I
> generation is so bad that debug builds probably won't be useful an= yways.

Could you elaborate on what happens? I'm not opposed to thi= s approach
as long as either (1) the configure test successfully determines that
CFI gen doesn't work on clang, or (2) the 'choking' just produc= es bad
CFI, but doesn't break the build.

T= he assembler errors out and doesn't produce any output. I have made the= test in ./configure more robust now, to work around this problem. Insertio= n of .cfi directives will not occur when building with clang, until it is f= ixed.
=C2=A0
> If that is a sticking point, I might put together a patch for LLVM and= see
> if they want it. Unfortunately, I have already discovered a bunch of o= ther
> problems with LLVM which would be nice to fix, but time for developing= and
> polishing patches is limited...

Why is -g even being processes for asm? Are they trying to
auto-generate CFI when it's not present? I think this really needs to be fixed in any case since there are plenty of .s files that _do_ have
CFI and build systems that use -g. All this points to clang's internal<= br> assembler being not-widely-tested and not ready for serious use... :(

GAS silently disables auto-generation of deb= ug info as soon as it sees an explicit debug directive. Clang gets ornery, = digs its heels in, and says: "forget it, you aren't getting nothin= g from me if you tell me to generate debug info but then provide your own&q= uot;.

Posting v9 patch now.
--001a113ed5ec0f7a93051888c4bf--