On Thu, Jul 26, 2018 at 03:58:45PM +0200, Thomas Huth wrote:
> On 07/26/2018 12:11 PM, Andrew Jones wrote:
> > On Thu, Jul 26, 2018 at 10:21:52AM +0200, Thomas Huth wrote:
> >> The .elf and .flat files are not runnable on the host operating system,
> >> so they should not be marked as executable. As we discovered recently,
> >> the executable flag can also cause trouble when the files are packaged
> >> in an .rpm file, since rpm "colors" the package differently if there
> >> are 32-bit or 64-bit executables in the package (for multilib support).
> >>
> >> Suggested-by: Laszlo Ersek <lersek@xxxxxxxxxx>
> >> Signed-off-by: Thomas Huth <thuth@xxxxxxxxxx>
> >> ---
> >> arm/Makefile.common | 2 ++
> >> powerpc/Makefile.common | 2 ++
> >> s390x/Makefile | 1 +
> >> x86/Makefile.common | 2 ++
> >> 4 files changed, 7 insertions(+)
> >>
> >> diff --git a/arm/Makefile.common b/arm/Makefile.common
> >> index 1cf9cdc..e62a978 100644
> >> --- a/arm/Makefile.common
> >> +++ b/arm/Makefile.common
> >> @@ -73,9 +73,11 @@ FLATLIBS = $(libcflat) $(LIBFDT_archive) $(libgcc) $(libeabi)
> >> -Wl,-T,$(SRCDIR)/arm/flat.lds,--build-id=none,-Ttext=$(start_addr) \
> >> $(filter %.o, $^) $(FLATLIBS) \
> >> $(SRCDIR)/lib/auxinfo.c -DPROGNAME=\"$(@:.elf=.flat)\" -DAUXFLAGS=$(AUXFLAGS)
> >> + chmod a-x $@
> >>
> >> %.flat: %.elf
> >> $(OBJCOPY) -O binary $^ $@
> >> + chmod a-x $@
> >>
> >> $(libeabi): $(eabiobjs)
> >> $(AR) rcs $@ $^
> >> diff --git a/powerpc/Makefile.common b/powerpc/Makefile.common
> >> index 81c5074..af6b9d8 100644
> >> --- a/powerpc/Makefile.common
> >> +++ b/powerpc/Makefile.common
> >> @@ -54,6 +54,7 @@ FLATLIBS = $(libcflat) $(LIBFDT_archive)
> >> -T $(SRCDIR)/powerpc/flat.lds --build-id=none \
> >> $(filter %.o, $^) $(FLATLIBS) $(@:.elf=.aux.o)
> >> $(RM) $(@:.elf=.aux.o)
> >> + chmod a-x $@
> >> @echo -n Checking $@ for unsupported reloc types...
> >> @if $(OBJDUMP) -R $@ | grep R_ | grep -v R_PPC64_RELATIVE; then \
> >> false; \
> >> @@ -70,6 +71,7 @@ $(TEST_DIR)/boot_rom.bin: $(TEST_DIR)/boot_rom.elf
> >> $(TEST_DIR)/boot_rom.elf: CFLAGS = -mbig-endian
> >> $(TEST_DIR)/boot_rom.elf: $(TEST_DIR)/boot_rom.o
> >> $(LD) -EB -nostdlib -Ttext=0x100 --entry=start --build-id=none -o $@ $<
> >> + chmod a-x $@
> >>
> >> powerpc_clean: libfdt_clean asm_offsets_clean
> >> $(RM) $(TEST_DIR)/*.{o,elf} $(TEST_DIR)/boot_rom.bin \
> >> diff --git a/s390x/Makefile b/s390x/Makefile
> >> index 6546a02..6b32f2c 100644
> >> --- a/s390x/Makefile
> >> +++ b/s390x/Makefile
> >> @@ -53,6 +53,7 @@ FLATLIBS = $(libcflat)
> >> $(CC) $(LDFLAGS) -o $@ -T $(SRCDIR)/s390x/flat.lds -Ttext=0x10000 \
> >> $(filter %.o, $^) $(FLATLIBS) $(@:.elf=.aux.o)
> >> $(RM) $(@:.elf=.aux.o)
> >> + chmod a-x $@
> >>
> >> arch_clean: asm_offsets_clean
> >> $(RM) $(TEST_DIR)/*.{o,elf} $(TEST_DIR)/.*.d lib/s390x/.*.d
> >> diff --git a/x86/Makefile.common b/x86/Makefile.common
> >> index 7dcf8c2..0d64284 100644
> >> --- a/x86/Makefile.common
> >> +++ b/x86/Makefile.common
> >> @@ -42,9 +42,11 @@ FLATLIBS = lib/libcflat.a $(libgcc)
> >> %.elf: %.o $(FLATLIBS) $(SRCDIR)/x86/flat.lds $(cstart.o)
> >> $(CC) $(CFLAGS) -nostdlib -o $@ -Wl,-T,$(SRCDIR)/x86/flat.lds \
> >> $(filter %.o, $^) $(FLATLIBS)
> >> + chmod a-x $@
> >>
> >> %.flat: %.elf
> >> $(OBJCOPY) -O elf32-i386 $^ $@
> >> + chmod a-x $@
> >>
> >> tests-common = $(TEST_DIR)/vmexit.flat $(TEST_DIR)/tsc.flat \
> >> $(TEST_DIR)/smptest.flat $(TEST_DIR)/port80.flat \
> >> --
> >> 1.8.3.1
> >>
> >
> > Can you please add '@' to the front of all these chmod lines? Otherwise
> > each unit test compilation gets two more lines of uninteresting output
> > when compiling.
>
> I don't think that we should arbitrarily add a '@' to lines which might
> be uninteresting at a first glance. What might be uninteresting for you,
> might be helpful for others to see what is going on. If you're not
> interested in the full output of make, simply compile with the "-s" option.
>
It's not arbitrary. Currently when I build I see lines I want to see. I
don't want to use -s to turn them off. With this patch I'll see the lines
I want and another 2 lines per unit test that I don't. How can hiding
these lines be harmful to a developer? They don't affect the build or
run in any way, and, as the commit message says, it's only being done
for packaging in the first place.
Thanks,
drew
