[CRIU] [PATCH 2/2] x86: ia32 -- Add needed bits to be compilable for x86-32

Cyrill Gorcunov gorcunov at gmail.com
Tue Apr 14 12:01:40 PDT 2015


On Tue, Apr 14, 2015 at 09:16:02AM -0400, Christopher Covington wrote:
> Hi Cyrill,

Hi Christopher!

> > +ifeq ($(ARCH),ia32)
> > +	SRCARCH      := x86
> > +	DEFINES      := -DCONFIG_X86_32
> > +	LDARCH       := i386
> > +	ldflags-y    += -m elf_i386
> > +	VDSO         := y
> > +	USERCFLAGS   += -m32
> 
> Do you have any thoughts on USERCFLAGS versus CFLAGS? Ideally to follow the
> usual convention CFLAGS could be set on the command line, on either side of
> make (right-hand clobbers makefile assignments while left-hand side gets
> clobbered makefile assignments). But that would have been a very invasive
> change so I just introduced USERCFLAGS.
> 
> It might be cleaner to have USERCFLAGS only ever set by the user and any
> makefile manipulation would be done on CFLAGS. Alternatively we could try to
> gradually change everything to append to USERCFLAGS so that eventually CFLAGS
> is equal to USERCFLAGS, CFLAGS can be properly used from the command line, and
> USERCFLAGS is a small backwards compatibility layer that could maybe
> eventually be deprecated and dropped.

You know, while preparing this series I started developing standalone
tool for make engine, and the final idea was to switch into it cleaning
all the makefile mess we have now, dropping off the USERCFLAGS but better
introduce something simial to kernel's EXTRA_CFLAGS. As to USERCFLAGS --
gimme sometime more time to think about all this, I wanna accumulate
somewhere all aspects of what we're building and how we're doing it
so we would modulate our make files and simplify them.

> >  
> >  $(PROGRAM): $(SYSCALL-LIB) $(ARCH-LIB) $(PROGRAM-BUILTINS)
> >  	$(E) "  LINK    " $@
> > -	$(Q) $(CC) $(CFLAGS) $^ $(LIBS) $(LDFLAGS) $(GMONLDOPT) -rdynamic -o $@
> > +	$(Q) $(CC) $(CFLAGS) $^ $(LIBS) $(GMONLDOPT) -rdynamic -o $@
> 
> I notice you're dropping LDFLAGS here and adding ldflags-y to some other
> rules. Why is that?

Ah, my bad, this get sneaked in from development files, should be reverted, thanks!
As to ldflags-y -- they are belonging to our makefiles only and can't (well,
shouldn't) be addected any variables set somwhere in make environment. LDFLAGS
is too common for that. Same time I wanna be close to kernel's make style that's
where this variable came from.

> >  
> > +#ifdef CONFIG_X86_64
> >  	err = syscall_seized(ctl, __NR_mmap, &map,
> > -			(unsigned long)addr, length, prot, flags, fd, offset);
> > +#else
> > +	err = syscall_seized(ctl, __NR_mmap2, &map,
> > +#endif
> > +			     (unsigned long)addr, length, prot, flags, fd, offset);
> >  	if (err < 0 || map > TASK_SIZE)
> >  		map = 0;
> 
> In my opinion it'd be easier to read and maintain something like #define
> PARASITE_MMAP_NR __NR_mmap in an x86_64 header, #define PARASITE_MMAP_NR
> __NR_mmap2 in an ia32 header, and have one syscall_seized that uses
> PARASITE_MMAP_NR in crtools.c.

Will do, thanks!


More information about the CRIU mailing list