On 07/26/18 16:22, Andrew Jones wrote:
> 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.
(I'm entirely neutral on this question.) What distinguishes the lines
you prefer to see from the new chmod lines? What is the information in
the pre-existent lines that is useful to see, and that the new chmod
lines lack?
I've only ever built kvm-unit-tests once (and an old version at that);
the lines that were interesting to me were:
gcc -mno-red-zone -m64 -O1 -g -MMD \
-MF x86/.tscdeadline_latency.d -Wall -fomit-frame-pointer \
-fno-stack-protector -nostdlib -o x86/tscdeadline_latency.elf \
-Wl,-T,x86/flat.lds \
x86/tscdeadline_latency.o x86/cstart64.o lib/libcflat.a \
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/libgcc.a
objcopy -O elf32-i386 \
x86/tscdeadline_latency.elf \
x86/tscdeadline_latency.flat
Here gcc and objcopy produce files with the executable mode bits set,
which is likely useful in the general case, but not useful in the
specific case. If we hide "chmod" with @, then someone used to objcopy
producing executable files might be surprised that the build product is
not executable after all -- the "make" output will not explain that.
Again, I'm perfectly fine both with and without silencing chmod, I'm
just curious about the information that sets the currently visible lines
apart from the chmod lines.
Thanks!
Laszlo
