Re: [PATCH v2] libgccjit: allow common objects in $(EXTRA_GCC_OBJS) and $(EXTRA_OBJS)

[David Malcolm <dmalcolm@redhat.com>]

On Mon, 2022-05-30 at 18:09 +0800, Xi Ruoyao wrote:
> Ping.  I'd like to see libgccjit working on LoongArch so I would be
> able
> to submit a Rust port to upstream.
> 
> If the result is NACK I'd like to know alternative approaches to fix
> the
> build failure.
> 
> I doubt if "jit@gcc.gnu.org" is really used, so CC'ed the JIT
> maintainer
> listed in MAINTAINERS.

Sorry about that, it turns out there's something wrong with my email
filters.  Unfortunately, I haven't been able to fix them, so please CC
me directly on jit-related patches, and do ping me if I seem not to
have seen one.  Sorry again.

> 
> On Thu, 2022-05-19 at 16:10 +0800, Yang Yujie wrote:
> > Hello,
> > 
> > This patch fixes libgccjit build failure on loongarch* targets,
> > and could probably be useful for future ports.
> > 
> > For now, libgccjit is linked with objects from $(EXTRA_GCC_OBJS)
> > and
> > libbackend.a, which contains object files from $(EXTRA_OBJS).
> > 
> > This effectively forbids any overlap between those two lists, i.e.
> > all
> > target-specific shared code between the gcc driver and compiler
> > executables must go into gcc/common/config/<arch>/<arch>-common.cc,
> > which feels a bit inconvenient when there are a lot of "common"
> > stuff
> > that we want to put into separate source files.
> > 
> > By linking libgccjit with $(EXTRA_GCC_OBJS_EXCLUSIVE), which
> > contains
> > all elements from $(EXTRA_GCC_OBJS) but not $(EXTRA_OBJS), this
> > problem
> > can be alleviated.

Yujie: thanks for figuring this out, and coming up with a solution. 
Presumably libgccjit is the only GCC "frontend" that also has driver
code directly linked into it, and thus the only one that needs this
workaround.

> > 
> > This patch does not affect any other target architecture than
> > loongarch,
> > and has been bootstrapped and regression-tested on loongarch64-
> > linux-
> > gnuf64
> > an x86_64-pc-linux-gnu.
> > 
> > Any recommendations? Please review. Thanks a lot.

The patch looks good to me.

Thanks.
Dave


> > 
> > Yujie
> > 
> > * gcc/jit/ChangeLog:
> > 
> >         * Make-lang.in: only link objects from $(EXTRA_GCC_OBJS)
> >         that's not in $(EXTRA_OBJS) into libgccjit.
> > ---
> >  gcc/jit/Make-lang.in | 9 +++++++--
> >  1 file changed, 7 insertions(+), 2 deletions(-)
> > 
> > diff --git a/gcc/jit/Make-lang.in b/gcc/jit/Make-lang.in
> > index 6e10abfd0ac..248ec45b729 100644
> > --- a/gcc/jit/Make-lang.in
> > +++ b/gcc/jit/Make-lang.in
> > @@ -157,18 +157,23 @@ LIBGCCJIT_EXTRA_OPTS =
> > $(LIBGCCJIT_VERSION_SCRIPT_OPTION) \
> >  endif
> >  endif
> >  
> > +# Only link objects from $(EXTRA_GCC_OBJS) that's not already
> > +# included in libbackend.a ($(EXTRA_OBJS)).
> > +EXTRA_GCC_OBJS_EXCLUSIVE = $(foreach _obj1, $(EXTRA_GCC_OBJS), \
> > +       $(if $(filter $(_obj1), $(EXTRA_OBJS)),, $(_obj1)))
> > +
> >  # We avoid using $(BACKEND) from Makefile.in in order to avoid
> > pulling
> >  # in main.o
> >  $(LIBGCCJIT_FILENAME): $(jit_OBJS) \
> >         libbackend.a libcommon-target.a libcommon.a \
> >         $(CPPLIB) $(LIBDECNUMBER) \
> >         $(LIBDEPS) $(srcdir)/jit/libgccjit.map \
> > -       $(EXTRA_GCC_OBJS) $(jit.prev)
> > +       $(EXTRA_GCC_OBJS_EXCLUSIVE) $(jit.prev)
> >         @$(call LINK_PROGRESS,$(INDEX.jit),start)
> >         +$(LLINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ -shared \
> >              $(jit_OBJS) libbackend.a libcommon-target.a
> > libcommon.a \
> >              $(CPPLIB) $(LIBDECNUMBER) $(EXTRA_GCC_LIBS) $(LIBS)
> > $(BACKENDLIBS) \
> > -            $(EXTRA_GCC_OBJS) \
> > +            $(EXTRA_GCC_OBJS_EXCLUSIVE) \
> >              $(LIBGCCJIT_EXTRA_OPTS)
> >         @$(call LINK_PROGRESS,$(INDEX.jit),end)
> >  
>