xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <jbeulich@suse.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: "Wei Liu" <wl@xen.org>, "Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [PATCH] x86emul: fix test harness build for gas 2.36
Date: Mon, 19 Apr 2021 16:41:20 +0100	[thread overview]
Message-ID: <5e6f7769-ba07-bccb-9d73-4c7c0db67f89@citrix.com> (raw)
In-Reply-To: <723af87e-329d-6f52-ece4-fc3314796960@suse.com>

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



  reply	other threads:[~2021-04-19 15:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-19 15:30 Jan Beulich
2021-04-19 15:41 ` Andrew Cooper [this message]
2021-04-19 15:51   ` Jan Beulich
2021-04-29  9:24     ` Ping: " Jan Beulich
2021-05-07  8:22       ` Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5e6f7769-ba07-bccb-9d73-4c7c0db67f89@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=roger.pau@citrix.com \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    --subject='Re: [PATCH] x86emul: fix test harness build for gas 2.36' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).