* [PATCH] x86emul: fix test harness build for gas 2.36 @ 2021-04-19 15:30 Jan Beulich 2021-04-19 15:41 ` Andrew Cooper 0 siblings, 1 reply; 5+ messages in thread From: Jan Beulich @ 2021-04-19 15:30 UTC (permalink / raw) To: xen-devel; +Cc: Andrew Cooper, Wei Liu, Roger Pau Monné 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] x86emul: fix test harness build for gas 2.36 2021-04-19 15:30 [PATCH] x86emul: fix test harness build for gas 2.36 Jan Beulich @ 2021-04-19 15:41 ` Andrew Cooper 2021-04-19 15:51 ` Jan Beulich 0 siblings, 1 reply; 5+ messages in thread From: Andrew Cooper @ 2021-04-19 15:41 UTC (permalink / raw) To: Jan Beulich, xen-devel; +Cc: Wei Liu, Roger Pau Monné 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] x86emul: fix test harness build for gas 2.36 2021-04-19 15:41 ` Andrew Cooper @ 2021-04-19 15:51 ` Jan Beulich 2021-04-29 9:24 ` Ping: " Jan Beulich 0 siblings, 1 reply; 5+ messages in thread From: Jan Beulich @ 2021-04-19 15:51 UTC (permalink / raw) To: Andrew Cooper; +Cc: Wei Liu, Roger Pau Monné, xen-devel 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Ping: [PATCH] x86emul: fix test harness build for gas 2.36 2021-04-19 15:51 ` Jan Beulich @ 2021-04-29 9:24 ` Jan Beulich 2021-05-07 8:22 ` Jan Beulich 0 siblings, 1 reply; 5+ messages in thread From: Jan Beulich @ 2021-04-29 9:24 UTC (permalink / raw) To: Andrew Cooper; +Cc: Wei Liu, Roger Pau Monné, xen-devel On 19.04.2021 17:51, Jan Beulich wrote: > 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. Besides there not having been any response from you so far, I'd like to point out that stripping the section is also what H.J. suggests in the referenced bugzilla entry. (As said there, I don't view this as an excuse to break use cases like ours by default, but that's orthogonal.) Jan ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Ping: [PATCH] x86emul: fix test harness build for gas 2.36 2021-04-29 9:24 ` Ping: " Jan Beulich @ 2021-05-07 8:22 ` Jan Beulich 0 siblings, 0 replies; 5+ messages in thread From: Jan Beulich @ 2021-05-07 8:22 UTC (permalink / raw) To: Andrew Cooper; +Cc: Wei Liu, Roger Pau Monné, xen-devel On 29.04.2021 11:24, Jan Beulich wrote: > On 19.04.2021 17:51, Jan Beulich wrote: >> 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. > > Besides there not having been any response from you so far, I'd like to > point out that stripping the section is also what H.J. suggests in the > referenced bugzilla entry. (As said there, I don't view this as an > excuse to break use cases like ours by default, but that's orthogonal.) Unless I hear back constructive feedback over the next week (while I'll be on PTO), I'm going to commit this as is, if need be without any acks, the week after. We shouldn't leave this broken; if you think you see better ways to address the original issue, you can always submit an incremental change later on. Jan ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-05-07 8:22 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-04-19 15:30 [PATCH] x86emul: fix test harness build for gas 2.36 Jan Beulich 2021-04-19 15:41 ` Andrew Cooper 2021-04-19 15:51 ` Jan Beulich 2021-04-29 9:24 ` Ping: " Jan Beulich 2021-05-07 8:22 ` Jan Beulich
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).