[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] x86emul: fix test harness build for gas 2.36
- To: Jan Beulich <jbeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
- Date: Mon, 19 Apr 2021 16:41:20 +0100
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Lu0ZOfWDtogrq3BaA/5ECWt1npO6miuYolO18GQiwzE=; b=B2pzsr6L3dVcrinSwG5IhVsnuowjBFGGmW4C4vRofFOhzDqbfkzdIv1o4CE0x2c7OY3cIb1ICOWZ+94B/df+r+l/s4dsxzGmI6Iy2eu0g4Pb68EpTuG9qLdQj5dhzstbaf+pjSkQxRLGj+vBUO9EMgULZv4BGbFcRFh0Q20PQk3Snn3ngXBugaB84jLSZ9iXE9HqEXV25L9f2XrByVLLzvy3Msycb46MFwPf/R24YqCmb5AloXjzgJlaUdrfmkZI215nN96LHDaEBBNWc4wcwcb5CbX3ifDoetPy543chxUdQxIOugbGd9BVwYyn6jYB575FDvaIxemGkHtzNubMbQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BLP+Jsd6Ch6nkW5eMMkET2vcaFnz9tIc9aD5H3OPQZ31MPlVGRZGnEHaM/fHI5WV0F5ySQ8TuytAITSBDPYT8ZT6k2Kjg4+4sXGy5tqkvv8T0ECGZSWceHgHCafsOfzO3bgmuivGMjJHhXu0Ag5wZuXLyJ40x0ffMi2E/UW3o1IaH2N5SuyBVpi2GUcYi2SWfTp/xBRmARswMwuF8m3SxHkJE2AyvXkxqMxXfQOipeXU70p1BMOLJP8lzc2YoLd2h9nuMUX7FRkWxGx4EzA0vMG/WgN0qV/iow0C7Fmb4p3IKq8wjs96Zc9QCRVCWVmNyVKoze/aLSctl0Ak4iYxtg==
- Authentication-results: esa4.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
- Cc: Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Delivery-date: Mon, 19 Apr 2021 15:41:36 +0000
- Ironport-hdrordr: A9a23:gyNs2KgKSWAyMrWQFiuR/cVUC3BQXwh13DAbvn1ZSRFFG/Gwv9 yynfgdyB//gCsQXnZlotybJKycWxrnmKJdy4N5B9efdSPhv3alK5wn0Jv6z1TbaknD38N+9Y MlSahxD9XsEUN35PyR3CCUG8stqePpzImGnuHbpk0CcShPS4VNqzh0ERyaFEoefngiObMcGI CH7sRK4xqMEE5nDfiTPXUOU+jdq9CjrvuPDSIuPBI79BKIyQqh9b+SKXOl9y0DWDBCy6pKyx mmryXF4MyY0s2T+1vn+EL4q79Xn9bgzdUrPr3wtuElbg/CpyztSIBoW7iptC04rue1+D8R4a XxiiZlBetfwTf8eXy0vAvM1mDboUkTwk6n83C0qz/CptH0Xz0zAcYpv/MmTjLpr3AOkfs59Y Aj5RP/i7NnSSnusQ642v3zEzZtrUawqWpKq59ps1VvFbEwRZUUkZYS5ypuYfE9NRO/0q8LOs 90AvrR4f5HGGnqFUzxjy1UzNugUm9bJGb+fmEy/sic0z1hlHtk1UcvxMsGgnca9J4mIqM0n9 j5Dg==
- Ironport-sdr: Fy0JXK6NypPBzdSGRLwDU+DRFfNBH+CI2iIQs1qQaUU4LrE6HB8FtI6lFg7wV8vyHhLPVF0TXZ Mq5OGdXItE3TMLe5esPt+sZodqieMKZU7eXsgvnBZKwFp559dwM+Q4BC/XKpWFIFNUXuIEgvsZ cB7biaSKqmHSNF7iYTWqsjUuXl7IWvaBZrg1A3Ojlqnv6Ryemui8zlS9zUglmsmE9DtgBOyH6E k5mG6mOQp6/v1uUvMQSxP2OgxAveMQUY7FxANVoM2808J3grj4WOXPAJRdQJMk2TRL1S8cpkl8 pmM=
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
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@xxxxxxxx>
>
> --- 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
|
