Mailing List Archive

[PATCH] x86emul: fix test harness build for gas 2.36
All of the sudden, besides .text and .rodata and alike, an always
present .note.gnu.property section has appeared. This section, when
converting to binary format output, gets placed according to its
linked address, causing the resulting blobs to be about 128Mb in size.
The resulting headers with a C representation of the binary blobs then
are, of course all a multiple of that size (and take accordingly long
to create). I didn't bother waiting to see what size the final
test_x86_emulator binary then would have had.

See also https://sourceware.org/bugzilla/show_bug.cgi?id=27753.

Rather than figuring out whether gas supports -mx86-used-note=, simply
remove the section while creating *.bin.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/tools/tests/x86_emulator/testcase.mk
+++ b/tools/tests/x86_emulator/testcase.mk
@@ -12,11 +12,11 @@ all: $(TESTCASE).bin
%.bin: %.c
$(CC) $(filter-out -M% .%,$(CFLAGS)) -c $<
$(LD) $(LDFLAGS_DIRECT) -N -Ttext 0x100000 -o $*.tmp $*.o
- $(OBJCOPY) -O binary $*.tmp $@
+ $(OBJCOPY) -O binary -R .note.gnu.property $*.tmp $@
rm -f $*.tmp

%-opmask.bin: opmask.S
$(CC) $(filter-out -M% .%,$(CFLAGS)) -c $< -o $(basename $@).o
$(LD) $(LDFLAGS_DIRECT) -N -Ttext 0x100000 -o $(basename $@).tmp $(basename $@).o
- $(OBJCOPY) -O binary $(basename $@).tmp $@
+ $(OBJCOPY) -O binary -R .note.gnu.property $(basename $@).tmp $@
rm -f $(basename $@).tmp
Re: [PATCH] x86emul: fix test harness build for gas 2.36 [ In reply to ]
On 19/04/2021 16:30, Jan Beulich wrote:
> All of the sudden, besides .text and .rodata and alike, an always
> present .note.gnu.property section has appeared. This section, when
> converting to binary format output, gets placed according to its
> linked address, causing the resulting blobs to be about 128Mb in size.
> The resulting headers with a C representation of the binary blobs then
> are, of course all a multiple of that size (and take accordingly long
> to create). I didn't bother waiting to see what size the final
> test_x86_emulator binary then would have had.
>
> See also https://sourceware.org/bugzilla/show_bug.cgi?id=27753.
>
> Rather than figuring out whether gas supports -mx86-used-note=, simply
> remove the section while creating *.bin.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> --- a/tools/tests/x86_emulator/testcase.mk
> +++ b/tools/tests/x86_emulator/testcase.mk
> @@ -12,11 +12,11 @@ all: $(TESTCASE).bin
> %.bin: %.c
> $(CC) $(filter-out -M% .%,$(CFLAGS)) -c $<
> $(LD) $(LDFLAGS_DIRECT) -N -Ttext 0x100000 -o $*.tmp $*.o
> - $(OBJCOPY) -O binary $*.tmp $@
> + $(OBJCOPY) -O binary -R .note.gnu.property $*.tmp $@
> rm -f $*.tmp
>
> %-opmask.bin: opmask.S
> $(CC) $(filter-out -M% .%,$(CFLAGS)) -c $< -o $(basename $@).o
> $(LD) $(LDFLAGS_DIRECT) -N -Ttext 0x100000 -o $(basename $@).tmp $(basename $@).o
> - $(OBJCOPY) -O binary $(basename $@).tmp $@
> + $(OBJCOPY) -O binary -R .note.gnu.property $(basename $@).tmp $@
> rm -f $(basename $@).tmp

Hmm - this is very ugly.  We don't really want to be stripping this
information, because it covers various properties of the binary which
need not to be lost, including stack-clash mitigations, and CET status.

We might be able to get away with saying that we're operating strictly
with defaults, and folding these *.bin's back into a program which is
also linked with defaults, at which point the resulting binary ought to
end up with a compatible .note.gnu.property section, but I'm not sure
how convinced I am by this argument.

~Andrew
Re: [PATCH] x86emul: fix test harness build for gas 2.36 [ In reply to ]
On 19.04.2021 17:41, Andrew Cooper wrote:
> On 19/04/2021 16:30, Jan Beulich wrote:
>> All of the sudden, besides .text and .rodata and alike, an always
>> present .note.gnu.property section has appeared. This section, when
>> converting to binary format output, gets placed according to its
>> linked address, causing the resulting blobs to be about 128Mb in size.
>> The resulting headers with a C representation of the binary blobs then
>> are, of course all a multiple of that size (and take accordingly long
>> to create). I didn't bother waiting to see what size the final
>> test_x86_emulator binary then would have had.
>>
>> See also https://sourceware.org/bugzilla/show_bug.cgi?id=27753.
>>
>> Rather than figuring out whether gas supports -mx86-used-note=, simply
>> remove the section while creating *.bin.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>
>> --- a/tools/tests/x86_emulator/testcase.mk
>> +++ b/tools/tests/x86_emulator/testcase.mk
>> @@ -12,11 +12,11 @@ all: $(TESTCASE).bin
>> %.bin: %.c
>> $(CC) $(filter-out -M% .%,$(CFLAGS)) -c $<
>> $(LD) $(LDFLAGS_DIRECT) -N -Ttext 0x100000 -o $*.tmp $*.o
>> - $(OBJCOPY) -O binary $*.tmp $@
>> + $(OBJCOPY) -O binary -R .note.gnu.property $*.tmp $@
>> rm -f $*.tmp
>>
>> %-opmask.bin: opmask.S
>> $(CC) $(filter-out -M% .%,$(CFLAGS)) -c $< -o $(basename $@).o
>> $(LD) $(LDFLAGS_DIRECT) -N -Ttext 0x100000 -o $(basename $@).tmp $(basename $@).o
>> - $(OBJCOPY) -O binary $(basename $@).tmp $@
>> + $(OBJCOPY) -O binary -R .note.gnu.property $(basename $@).tmp $@
>> rm -f $(basename $@).tmp
>
> Hmm - this is very ugly.  We don't really want to be stripping this
> information, because it covers various properties of the binary which
> need not to be lost, including stack-clash mitigations, and CET status.

Could you clarify who you think wants to consume this information from
these format-less binary blobs? They're strictly internal to the test
harness.

> We might be able to get away with saying that we're operating strictly
> with defaults, and folding these *.bin's back into a program which is
> also linked with defaults, at which point the resulting binary ought to
> end up with a compatible .note.gnu.property section, but I'm not sure
> how convinced I am by this argument.

Well, if we want to make it complicated, we could of course extract
the notes into a separate ELF object, and include that object in the
linking process. But these notes are wrong anyway: Whichever insns the
blobs use, test_x86_emulator does _not_ need CPU support for them, as
it'll suitably avoid executing any of the blobs. Similarly stack and
CET related information is not of interest for the blobs, only for the
"normal" object files.

Jan