[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Build errors with fuzz/x86_instruction_emulator harness
- To: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>
- From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
- Date: Mon, 14 Aug 2023 15:52:01 +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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=h3r8VfZzQv1nlbZXaNy+XstpNnDPjhYt0XOpBlcOWKs=; b=aYzJzSHcyHfFGK2Y58KRS7xHaLxj5vfGPgSwPwMeg1fdvGBVIqPH5+OLCEBiWug5NymhzToyVrDIcWjbIYFvCJIvZvXYdqj3i/0PW0n4d0dtN+72iDHUi4oAq3/uOILXYqOH9MQZYPlDVgVziU32y+pk4SP1o8vqFyM7adSBmcxQU4XyrNwEmU/RUbwX5CYc6lQM2Z+NqzUxNjYMhOcj8+59Y3HoxCJrvfJlBrKmsKHPDUKJmSLkTUEYyfzSus+hBos8DQOsd7PNArd8uBfTSqOdQsrOvuAILFJi/0wjeyMilY9BF1RroqttHSYfDrxKc90A3yrZ8yQIoCKadObktw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l9dsW5LQ84C0RFMjZr9nFKW4UfRw9lDZpK4KlMMqBb0WeyOaTisaHRqHOFslt+GHwG5g74dBLpsiGjwAjyGRDtRRe2T/aNS1gkz0Mp7WN8KuHZfryg23q80inm7T+4XQ5RAYQ/Mo3/1sK63K9w7NGlV+sGJvdbLRDB/BQJihdF2W4NK7/825Ei+oW6lVw0ghK832tJF72rklFz63REO7Q02JKjveZ+yyTjo/g0kVNUm3QaWV9XNcUkaoQq7rS/qr95qsRzRqN7jzVpPxabk2YpEKx0f2zrWKnrvvU1933yN+XBbkNclwsZjme7MgKESCP27SKddjyStAEIbgAWR3+Q==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Delivery-date: Mon, 14 Aug 2023 14:52:30 +0000
- Ironport-data: A9a23:SuogTK+a5yu9ZIxARbPRDrUDHH+TJUtcMsCJ2f8bNWPdYAtSk2BPi n1XRDXZbc8+UBK9c98ZMdP1qyVT5NOJ0Io8HzLYnlk8Q3xDo8OfWozAJUr9YS7NIpHIFkg5t stENNeYdZ5rFyHQrUv2Y+C79iMgjviBH+GhUbebN3t9HQE5FCwog0ho8wJVbvaEpPDga+/ak Y6q+pS31CaZ5gNJ3kIoB4Or9k9l7aip5TlCtQRia69HsgSHmnRJBpwRe/rqJirzG9MFQuLiS +j9l7zopWmxEzXBqD+Guu2iLhBVGO660Sym0Cc+t32K20AazsAK+v9ncqFaMQEP0G/hc+lZk L1lrYa3RRoiIprCkeEcVwgwOyxlNOhN9aSvzUKX6KR/9GWYNSO1qxlSJBtuZ9ZAqr8rWTgmG cEwc1jhUDjS34pa/5rjIgVcrpxLBNXmOooZpkZhwVnxZRrxacmeK0lizYYwMAYY3qiiL96HD yYqQWMHgCD7Sw9OIj8q5KcWx49EsJVdnwpw8zp5rYJvi4TaIZcYPLLFaLI5cfTSLSlZc9rxS ssrMA0VDzlDXOFzxwZp/VqHoMXqoQnwcbsABZaz8fA3pXyoxGAcXUh+uVuT+ZFVi2aYcvcGc QkxxXBrqqI/sku2UtP6Qhu05maeuQIRUMZRFOt87xyRzq3T4ECSAW1sojxpMYR68pNpA2J0k APV9z/qLWUHXLm9YHSR7LqL6xi1PjAYNzQqbi4YVwoVpdLkpenfizqWF4Y6Svfl0YKd9TfYn DeDvAMUgZUvjsMFkKSA52v3gBCzn82cJuIyzkCNNo6/1StpaYjga4G25Fzz6fdbMJ3fXlSHp GIDmcWV8KYJF57lvC6HTfgJHbqpz+2YKzCaillqd6TN7Byo8n+nOIVPujd3IR4zNt5eIWO1J kjOpQlW+ZlfemOwarN6aJ6wDMJsyrX8EdPiVbbfad8mjoVNSTJrNRpGPSa4t10BWmB1+U3jE f93qfqRMEs=
- Ironport-hdrordr: A9a23:BcbkEK3clTKppO56lMz+dgqjBHYkLtp133Aq2lEZdPU0SKGlfq GV7ZEmPHrP4gr5N0tOpTntAse9qBDnhPxICOsqXYtKNTOO0AeVxelZhrcKqAeQeBEWmNQ96U 9hGZIOcuEZDzJB/LvHCN/TKadd/DGFmprY+ts31x1WPGVXgzkL1XYANu6ceHcGIzVuNN4CO7 e3wNFInDakcWR/VLXBOpFUN9KzweEijfjdEGc7OyI=
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
Hello,
See the attached log snippet. This is current staging, with a GCC 13
toolchain.
First of all, a minor issue. Counting the number of
`-D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__`'s, we
have included CFLAGS on the CC line 4 times. This is something that
appears to be in common with all of tools/ and is probably the primary
contributor to exceeding the Gitlab CI 4M log limit...
Next the error. This doesn't build when CFLAGS coming in from the
packaging environment include `-flto=auto`.
Clearly our wrapping trick doesn't work with LTO, but it's not obvious why.
readelf -Wa tools/fuzz/x86_instruction_emulator/wrappers.o | grep emul_
[223] .gnu.lto_emul_fwrite.38.43da3a7fd30cc0a1 PROGBITS
0000000000000000 01c2ec 000194 00 E 0 0 1
[224] .gnu.lto_emul_memcmp.39.43da3a7fd30cc0a1 PROGBITS
0000000000000000 01c480 0001a7 00 E 0 0 1
[225] .gnu.lto_emul_memcpy.40.43da3a7fd30cc0a1 PROGBITS
0000000000000000 01c627 000175 00 E 0 0 1
[226] .gnu.lto_emul_memset.41.43da3a7fd30cc0a1 PROGBITS
0000000000000000 01c79c 000186 00 E 0 0 1
[227] .gnu.lto_emul_printf.42.43da3a7fd30cc0a1 PROGBITS
0000000000000000 01c922 0002cd 00 E 0 0 1
[228] .gnu.lto_emul_putchar.43.43da3a7fd30cc0a1 PROGBITS
0000000000000000 01cbef 000216 00 E 0 0 1
[229] .gnu.lto_emul_puts.44.43da3a7fd30cc0a1 PROGBITS
0000000000000000 01ce05 000180 00 E 0 0 1
shows that there's something relevant in the object file.
Manual poking about in the build environment indicates that
tools/tests/x86_instruction_emulator is similarly impacted.
Any ideas?
Obviously we can inhibit LTO for the x86_emul userspace, but that ought
to be a last resort.
~Andrew Attachment:
x86_insn_emul.log
Description: Text Data
|