From nobody Sat Aug 5 00:17:28 2023 X-Original-To: freebsd-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 4RHjp40g90z4mJ1S for ; Sat, 5 Aug 2023 00:17: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 4RHjp35ZLGz3R5w for ; Sat, 5 Aug 2023 00:17:31 +0000 (UTC) (envelope-from yuri@aetern.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=aetern.org header.s=fm3 header.b=LgMqyp+s; dkim=pass header.d=messagingengine.com header.s=fm3 header.b="d KVcgYv"; 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 compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 807795C0166 for ; Fri, 4 Aug 2023 20:17:30 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Fri, 04 Aug 2023 20:17: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:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1691194650; x=1691281050; bh=JnDNes/G/DjBKSDynQ4R9VH3q27CXvNcVXK VCsR8BpQ=; b=LgMqyp+sUNa2FwdeEipTbR3lZanoc1i/Ap8ReeleY8MC8BOQvC8 0ihLaSWRK6XDE3OhnbEVhJPH6dYAp8WaZes+2XSz3r8gq0uStet1m2GRNHOTHpUO Hy8V5Q9a5/GeqwD5LovCW3yt5IUxj9JdbHbPryIGK2Ii1zhDwz4zGvST3MIYUU+0 oD+R7AqrFtf8i+6mI2mBtVk+hnhiNcQMNvy6lVk983xGw0WEQj5cenOFKTzjNF0s fnfswdWOH6BPsEnpzxXyec3ZKkaSCellLpjty4G/TIuLTsdNgGDKVJvhzdptUU5h eejKSZ96qHvDVSXqH3N0QciptRbv4ikL0yg== 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:in-reply-to:message-id:mime-version:references :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=1691194650; x= 1691281050; bh=JnDNes/G/DjBKSDynQ4R9VH3q27CXvNcVXKVCsR8BpQ=; b=d KVcgYvv9MKMD3Tmnzl0vb0j5c+eZn3L0RCV5UUcSTWxuDqZInp/oqiCUfzrv1YWa 7iXoj1t0pmqXJVRWcH4Nm+uM8TTOlQdRxDyiQmSo4L4aOi+YFDFabp1oViBff93q bw7CWYnnj9b+rliZ0JfXxsO1fzXs8q+k1Uu0rys3aNBPCkGmlhFUtdxb9da32iGR Jcp+Z/zteiuPpQ4jqZNWI6es1yeOmcp4NYsJ3edneYhM3Pjqb0f83yMac31QERvv P26MSCdFi5j3FUmjhM++ANHTP1jwWYJi1ChdX78XBmxy3qCXOUgicyp8qU8XFBvm buSRGJhoMZYwIQWb/InKg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrkeehgddvlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepkfffgggfuffvfhfhjggtgfesthejre dttddvjeenucfhrhhomhepjghurhhiuceohihurhhisegrvghtvghrnhdrohhrgheqnecu ggftrfgrthhtvghrnhepgfdvhfdtjeeggfelfefggefggeffgfetffelieegfeeiheevgf dutedtuedvueevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf rhhomhephihurhhisegrvghtvghrnhdrohhrgh X-ME-Proxy: Feedback-ID: i0d79475b:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Fri, 4 Aug 2023 20:17:29 -0400 (EDT) Message-ID: Date: Sat, 5 Aug 2023 02:17: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 Subject: Re: amd64-gcc12 seems to break linker sets Content-Language: en-US To: freebsd-hackers@freebsd.org References: <6a0f626c-95b4-2398-0a6d-9428c440131b@aetern.org> From: Yuri In-Reply-To: <6a0f626c-95b4-2398-0a6d-9428c440131b@aetern.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4RHjp35ZLGz3R5w 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_SPF_ALLOW(-0.20)[+ip4:66.111.4.29]; R_DKIM_ALLOW(-0.20)[aetern.org:s=fm3,messagingengine.com:s=fm3]; XM_UA_NO_VERSION(0.01)[]; DKIM_TRACE(0.00)[aetern.org:+,messagingengine.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; local_wl_from(0.00)[yuri@aetern.org]; FREEFALL_USER(0.00)[yuri]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US] Yuri wrote: > 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? Apparently it's any gcc version (starting with oldest available in ports, 4.8) and it's something that was changed in: --- commit 32231805fbe2b9438c2de50c229b43c016207a08 Author: Greg V Date: Tue Apr 20 01:47:15 2021 +0100 linker_set: fix globl/weak symbol redefinitions to work on clang 12 --- While fixing clang, it seems to broke gcc. The following patch (reverting to previous definition for !clang) seems to work for both clang and gcc, dtraceall kld loads successfully, dtrace shows all defined std probes: diff --git a/sys/sys/cdefs.h b/sys/sys/cdefs.h index 1de042339c3..e1d3cf636dd 100644 --- a/sys/sys/cdefs.h +++ b/sys/sys/cdefs.h @@ -562,7 +562,11 @@ #endif /* __GNUC__ */ #define __GLOBL(sym) __asm__(".globl " __XSTRING(sym)) +#ifdef __clang__ #define __WEAK(sym) __asm__(".weak " __XSTRING(sym)) +#else +#define __WEAK(sym) __GLOBL(sym) +#endif #if defined(__GNUC__) #define __IDSTRING(name,string) __asm__(".ident\t\"" string "\"")