From nobody Fri Aug 4 22:48:28 2023 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RHgqN75VBz4mBFh for ; Fri, 4 Aug 2023 22:48:32 +0000 (UTC) (envelope-from yuri@aetern.org) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RHgqN1Kfhz3F0w for ; Fri, 4 Aug 2023 22:48:31 +0000 (UTC) (envelope-from yuri@aetern.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=aetern.org header.s=fm3 header.b=IhVNJTCO; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=SzBj6KD4; spf=pass (mx1.freebsd.org: domain of yuri@aetern.org designates 66.111.4.29 as permitted sender) smtp.mailfrom=yuri@aetern.org Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 8285C5C00EA for ; Fri, 4 Aug 2023 18:48:30 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Fri, 04 Aug 2023 18:48:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aetern.org; h=cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:message-id:mime-version:reply-to:sender :subject:subject:to:to; s=fm3; t=1691189310; x=1691275710; bh=cf hwTMBn4cxqWk5W5atKCTQrvqExHN3jLyHYLV7MxOw=; b=IhVNJTCOI/vG9GuGkg RecgFqeiN7WVyg96l+xABSxugorD3t45Y5QeWmBXLpDeIdAZbnzTCS4qT0zlGA9f sX/tBVLZuqw/vcgeDQ4DlLyvNQfG2QYwXIG5V5LTUlzK1AWOrWWvgynUY6S6oUut uYkU6GunDN8r5a3MbCz3gJ8ck2OlUIw/n1QClnQ1UrjBDE3J5Cuan0nlfjGOLpOB UBmNJFOc+bggpiV32nGzlx2NB6OdRg+tBDjXcQucGM3lIGQlPPx3Tw8jvNOK0S1I 9u6Tf8WJ9EcC3zIYVT9AqtHZCWmaQj5PcCnLUln28T3b9ZHAN6cADtqIwPuGBi6M bULg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:message-id:mime-version:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; t=1691189310; x=1691275710; bh=cfhwTMBn4cxqW k5W5atKCTQrvqExHN3jLyHYLV7MxOw=; b=SzBj6KD4MI544oz3OTNdpldOujKJ2 r9oYrXkA8egN6itTTNti+IIlHZ+/lzYAfr1+hxFKaFD/HTssHYbfdSEeZtwmTz9g aoIXnyGZLaz1SQayZey8qxskJD0dj1kKqxLgpMq3PHVbcUad8QwpzQsCN//dO5/b GpMpWIhf7Fzqsq758FBxavJCSZckdYZVUbDG6HLZRX3A9cjdnJsc5Rmi0hO/NhAh AW78qLh6q+4x28LFlihg6SrALm/WfrLlBaIdmlF4NqvyS0swBmOdPt6OoYEVuc9Q ZLGOjehpF9JEXZ/xQH68+A2ACiIFl8RR422mqbWRnxAYEO4MPI01/85Tg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrkeehgdduudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepkfffgggfvffhufgtgfesthejredttd dvjeenucfhrhhomhepjghurhhiuceohihurhhisegrvghtvghrnhdrohhrgheqnecuggft rfgrthhtvghrnhepgeevkeegueefudehjeelledtvdefiedvvdefhfdvjefgfeejleeghe ehudettdeunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhho mhephihurhhisegrvghtvghrnhdrohhrgh X-ME-Proxy: Feedback-ID: i0d79475b:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Fri, 4 Aug 2023 18:48:29 -0400 (EDT) Message-ID: <6a0f626c-95b4-2398-0a6d-9428c440131b@aetern.org> Date: Sat, 5 Aug 2023 00:48:28 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: hackers@freebsd.org From: Yuri Subject: amd64-gcc12 seems to break linker sets Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4RHgqN1Kfhz3F0w X-Spamd-Bar: / X-Rspamd-Pre-Result: action=no action; module=multimap; Matched map: local_wl_from X-Spamd-Result: default: False [-0.39 / 15.00]; R_DKIM_ALLOW(-0.20)[aetern.org:s=fm3,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.29]; XM_UA_NO_VERSION(0.01)[]; local_wl_from(0.00)[yuri@aetern.org]; MLMMJ_DEST(0.00)[hackers@freebsd.org]; FREEFALL_USER(0.00)[yuri]; DKIM_TRACE(0.00)[aetern.org:+,messagingengine.com:+]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US] I noticed that kernel built using amd64-gcc12 panics on `kldload dtraceall`: panic: probe defined without a provider cpuid = 4 time = 1691186663 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x35/frame 0xfffffe00c448b8a0 vpanic() at vpanic+0x232/frame 0xfffffe00c448b950 panic() at panic+0x3c/frame 0xfffffe00c448b9b0 sdt_kld_load_probes() at sdt_kld_load_probes+0x346/frame 0xfffffe00c448bb70 sdt_load_probes_cb() at sdt_load_probes_cb+0x9/frame 0xfffffe00c448bb80 linker_file_foreach() at linker_file_foreach+0x53/frame 0xfffffe00c448bbc0 linker_load_dependencies() at linker_load_dependencies+0xe18/frame 0xfffffe00c448bc70 link_elf_load_file() at link_elf_load_file+0x10c6/frame 0xfffffe00c448bd50 sys_kldload() at sys_kldload+0x820/frame 0xfffffe00c448bdf0 amd64_syscall() at amd64_syscall+0x11b/frame 0xfffffe00c448bf30 fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe00c448bf30 --- syscall (304, FreeBSD ELF64, kldload), rip = 0x7e7e919615a, rsp = 0x7e7e70ef498, rbp = 0x7e7e70efa10 --- Looking into it, gcc12 seems to discard the __start_set_... and __stop_set_... symbols declared in sys/linker_set.h as __WEAK(), i.e. __asm__(".weak ..."). The following small test shows the problem: --- int main(void) { return (0); } __asm__(".weak __start_set_sdt_providers_set"); static void const * const __set_sdt_providers_set_sym_sdt_provider_tst __attribute__((__section__("set_" "sdt_providers_set"))) __attribute__((__used__)) = &(main); __asm__(".weak __stop_set_sdt_providers_set"); --- When built using system clang: --- $ cc -c -o t.o t.c; nm t.o 0000000000000000 r __set_sdt_providers_set_sym_sdt_provider_tst w __start_set_sdt_providers_set w __stop_set_sdt_providers_set 0000000000000000 T main --- When built using amd64-gcc12: --- $ /usr/local/bin/x86_64-unknown-freebsd14.0-gcc12 -c -o t.o t.c; nm t.o 0000000000000000 r __set_sdt_providers_set_sym_sdt_provider_tst 0000000000000000 T main --- I haven't found any options to tell gcc to stop doing that; any hints?