From nobody Sat Aug 5 00:42:46 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 4RHkMD635bz4mKj3 for ; Sat, 5 Aug 2023 00:42:48 +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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RHkMD4RVkz3TX9 for ; Sat, 5 Aug 2023 00:42:48 +0000 (UTC) (envelope-from yuri@aetern.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=aetern.org header.s=fm3 header.b=vRiR5fkc; dkim=pass header.d=messagingengine.com header.s=fm3 header.b="D JsP8O6"; spf=pass (mx1.freebsd.org: domain of yuri@aetern.org designates 66.111.4.29 as permitted sender) smtp.mailfrom=yuri@aetern.org; dmarc=none Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 3B3D85C00B4 for ; Fri, 4 Aug 2023 20:42:48 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Fri, 04 Aug 2023 20:42:48 -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= 1691196168; x=1691282568; bh=uv+fx7C0Wjpeg1dpCzUT5v8JlLpoZNMIsDx X4b7janA=; b=vRiR5fkcxg87icAHZBWaP62MmboHtITzMafAiVu3Mc364b9nHeZ eAGnYcQgAeW+naGS1k+QGYaRZowYvY3boQAcgQpoI2X+J/g6BH64V41rXkKowVqw 85P6ln855FuWhWJleiUrdwGFhQ3ThzM7aJ9hXJxX344ZU4doVoFhtUcfaEpDZIvJ LoE7YloS+j8fJyPbRJsmBkVptHgGzjcIUatMoywPUWzIZaMVGJKMp1ZSruZ2SfVM kHyjnm4q2jYFwOpjBz355e87v9vEuZ10lHuO/wbms6ROyITLmnJJwIhh1vrfc25Q xLghRsTBaGLy6ywBwAgVkZIvB7g3CvnzEGg== 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=1691196168; x= 1691282568; bh=uv+fx7C0Wjpeg1dpCzUT5v8JlLpoZNMIsDxX4b7janA=; b=D JsP8O6QABjO+Ajh0RfJxw7Qw67utf42l4vYiH0WVfA57Levr/odxA15CZMiv3Io+ ZkfsX4HtyH4I7bSB+N6N5c0k1zqD3LlUaclLdjQ1CjRmfJI2JtEhzU3ZR5Ce8rey iSGE6/mBmNA9pMG8amKu0h6VnXy2PdZH7OzsvpdUZYieQv/Sq9hiRc3KaMLV2qTN Bb0+JSl9vQnN2zJB8JNy2uwsB8eb9feA1y+Z4fmIyUeblNtZuA8eBcxwV2iKKp39 EOcxEbDCXhT+Tc3v/RSNAQl0GsUrfOHcJo2LL92Yp7XF721Yh08jVlOgkjTNj0wR nUW61ksIM6c2RskmqqfCA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrkeehgdeffecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepkfffgggfuffvfhfhjggtgfesthejre dttddvjeenucfhrhhomhepjghurhhiuceohihurhhisegrvghtvghrnhdrohhrgheqnecu ggftrfgrthhtvghrnhepveekhfefffeghfehleeglefhkeegtdelgfdvledvueefhefhte ejieekfefgffelnecuffhomhgrihhnpehfrhgvvggsshgurdhorhhgnecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhephihurhhisegrvghtvghrnh drohhrgh X-ME-Proxy: Feedback-ID: i0d79475b:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Fri, 4 Aug 2023 20:42:47 -0400 (EDT) Message-ID: <4daecfde-80bf-d81e-3f0b-367db1a95ef2@aetern.org> Date: Sat, 5 Aug 2023 02:42:46 +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: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4RHkMD4RVkz3TX9 X-Spamd-Bar: - X-Rspamd-Pre-Result: action=no action; module=multimap; Matched map: local_wl_from X-Spamd-Result: default: False [-1.89 / 15.00]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; RWL_MAILSPIKE_EXCELLENT(-0.40)[66.111.4.29:from]; R_DKIM_ALLOW(-0.20)[aetern.org:s=fm3,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.29:c]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.29:from]; XM_UA_NO_VERSION(0.01)[]; DKIM_TRACE(0.00)[aetern.org:+,messagingengine.com:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; FREEFALL_USER(0.00)[yuri]; DMARC_NA(0.00)[aetern.org]; local_wl_from(0.00)[yuri@aetern.org]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US] Yuri wrote: > 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 "\"") > https://reviews.freebsd.org/D41329