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))))
> > >       $(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.

> 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... :(