From nobody Sun Jun 5 19:44:32 2022 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 380ED1BD0D22 for ; Sun, 5 Jun 2022 19:45:00 +0000 (UTC) (envelope-from nyan@myuji.xyz) 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 4LGRsl2MR9z3PCF for ; Sun, 5 Jun 2022 19:44:59 +0000 (UTC) (envelope-from nyan@myuji.xyz) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id F02DA5C00C8; Sun, 5 Jun 2022 15:44:53 -0400 (EDT) Received: from imap45 ([10.202.2.95]) by compute4.internal (MEProxy); Sun, 05 Jun 2022 15:44:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=myuji.xyz; h=cc :cc: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=fm1; t=1654458293; x=1654544693; bh=w14mcqoWVz 0y+8nN4xr/UavskqYEQ8FtlnW1cCnaAp8=; b=9LJhfFf91CLi7CFRvEq1fIXMoL kRv2Ny7pkKm7YhDv1Xb/7GKRYsGNb2zicK/EF0+7yySTrAzHIskegV0lw8DgV96f Lkp27PMmW9G3forg5ZioMUxjv/9ZJw7SnzsW5tt4wELlO0XIygC4fscBpLGhfrg7 jR6ypCU2Q3Gsfp8612El5967QocitFlFaJ5iy2YDjJ7tzr5M5fHRETFxVqBDavdx 1JstwPttflkmeoW6mEh0r7xRDY6UCGOJJUVchXAR7urIOUcpU9zQBr0paQoN0OEA +CElXTlbk3gkzc8ne/xWxflzzTiTHVfIaxZf/ESRAAO/oMXA2d7GbeodzAYA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc: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= fm1; t=1654458293; x=1654544693; bh=w14mcqoWVz0y+8nN4xr/UavskqYE Q8FtlnW1cCnaAp8=; b=tzbZCuAAYl3SffR16qPtmccDEExp5bHsk/qXBUSF/lp0 zpraJ8y2OAnMLCiisWHMchoGrANVv8Y7nmqcZC+tgk3KqFOHE9Mov0yf7vow3Wg1 Wx+4HDjwgq0wkU5IvlkoseiiQdlfm0mRTLt0/jgYlTJAOEfYq0rer1En7voTX7IN Mccvghgar3KvQ8nFt3AlMQ6AdFQAm1sx3S5ShSQtJ7lWsSrzKl7i08kHuu2lv/3T 91Y/88McFV5HwLC3km6oG15f2pplocav6HYlNOUHDP0kWx+w77XvmCWuSOIZvuwN Eaz9fhJhZdbHTf4acz2iyUOxRlRzW9WsUUr3Rztmvw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedruddttddgudegudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecufghrlhcuvffnffculdefhedmnecujfgurhepof gfggfkjghffffhvfevufgtsegrtderreerreejnecuhfhrohhmpedfofhitghhrggvlhcu jggrnhcumfgrucevhhhiuhdfuceonhihrghnsehmhihujhhirdighiiiqeenucggtffrrg htthgvrhhnpedutdektdegtdeujedtlefhhfeitddutdekleeggfeuvddtgffhveffieeu udffjeenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhrvggtohhrugdrrhhsnecuve hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepnhihrghnsehm hihujhhirdighiii X-ME-Proxy: Feedback-ID: i9dd946d0:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id AB4E52720074; Sun, 5 Jun 2022 15:44:53 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-591-gfe6c3a2700-fm-20220427.001-gfe6c3a27 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 Message-Id: <51c74c5b-731a-445f-be96-0baf6cd0ebe2@www.fastmail.com> In-Reply-To: References: Date: Mon, 06 Jun 2022 03:44:32 +0800 From: "Michael Yan Ka Chiu" To: "Konstantin Belousov" Cc: freebsd-hackers@freebsd.org Subject: Re: Help needed to get Rust dtrace USDT working on/with FreeBSD linker Content-Type: multipart/alternative; boundary=10660d8e775940ae9e59aa67b16a4e69 X-Rspamd-Queue-Id: 4LGRsl2MR9z3PCF X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=myuji.xyz header.s=fm1 header.b=9LJhfFf9; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=tzbZCuAA; dmarc=none; spf=pass (mx1.freebsd.org: domain of nyan@myuji.xyz designates 66.111.4.29 as permitted sender) smtp.mailfrom=nyan@myuji.xyz X-Spamd-Result: default: False [-3.57 / 15.00]; XM_UA_NO_VERSION(0.01)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.29]; RCVD_COUNT_THREE(0.00)[4]; DKIM_TRACE(0.00)[myuji.xyz:+,messagingengine.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.98)[-0.980]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.29:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[myuji.xyz:s=fm1,messagingengine.com:s=fm1]; FREEFALL_USER(0.00)[nyan]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[myuji.xyz]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N --10660d8e775940ae9e59aa67b16a4e69 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Mon, Jun 6, 2022, at 3:01 AM, Konstantin Belousov wrote: > On Sun, Jun 05, 2022 at 04:26:37PM +0800, Michael Yan Ka Chiu wrote: > > Hi everyone, > >=20 > > I=E2=80=99m working on a PR to get the Rust Usdt crate working on Fr= eeBSD. This crate > > basically allow adding DTrace probes to rust sources by compiling th= e probe during > > macro invocation and embed to a custom section (set_dtrace_probe) us= ing inline=20 > > assembly. > >=20 > > The problem I am encountering is that the linker will optimize the c= ompiled probes > > out in the custom section, the only workaround I have found is to fo= rce the linker to > > link all the dead code by invoking `-C link-dead-code=3Dyes`. On Ill= umos, the workaround > > is to reference another section such that the Illumos linker will no= t throw the probes=20 > > away; however the same workaround does not work on FreeBSD. > >=20 > > I wonder if there're any tricks similar to the Illumos fix, by putti= ng some inline asm there > > to trick the linker and not throw out the probes. > >=20 > > Thanks In advance, > > Michael > >=20 > > References: > > The PR: https://github.com/oxidecomputer/usdt/pull/63 > > The illumos fix: https://github.com/oxidecomputer/usdt/blob/eac0fe5f= 03c3fbf23468ead5cb140f62d51ac3f3/usdt-impl/src/record.rs#L251 > >=20 > > =20 >=20 > GNU as seems to gain support for the "R" flag for sections, which shou= ld > prevent them from linker GC. Not sure if llvm toolchain has this, it > requires both as and lld to recognize the flag. >=20 > Anyway, try it? See GNU as documentation for the .section directive, > ELF type flags. Thanks! This seems to solve a big part of the issue. If i pass =E2=80=9Ccargo:rustc-link-arg=3D-Xlinker=E2=80=9D and =E2=80=9C= cargo:rustc-link-arg=3D=E2=80=94no-gc-sections=E2=80=9D it does prevent = the linker from removing the probes. I am still looking for solutions that does not involve explicit involvem= ent of the flags by the crate consumer, and maybe something not turning = gc off entirely but this is a great progress. --10660d8e775940ae9e59aa67b16a4e69 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jun 6, = 2022, at 3:01 AM, Konstantin Belousov wrote:
On Sun, Jun 05, 2022 at 04:26:37PM +080= 0, Michael Yan Ka Chiu wrote:
> Hi everyone,
<= div>> 
> I=E2=80=99m working on a PR to get the= Rust Usdt crate working on FreeBSD. This crate
> basic= ally allow adding DTrace probes to rust sources by compiling the probe d= uring
> macro invocation and embed to a custom section = (set_dtrace_probe) using inline 
> assembly.
> 
> The problem I am encountering is = that the linker will optimize the compiled probes
> out= in the custom section, the only workaround I have found is to force the= linker to
> link all the dead code by invoking `-C lin= k-dead-code=3Dyes`. On Illumos, the workaround
> is to = reference another section such that the Illumos linker will not throw th= e probes 
> away; however the same workaround does= not work on FreeBSD.
> 
> I wond= er if there're any tricks similar to the Illumos fix, by putting some in= line asm there
> to trick the linker and not throw out = the probes.
> 
> Thanks In advanc= e,
> Michael
> 
>= ; References:
> 
>  

GNU as seems to gain support for the "R" flag for sect= ions, which should
prevent them from linker GC.  Not = sure if llvm toolchain has this, it
requires both as and l= ld to recognize the flag.

Anyway, try it?&n= bsp; See GNU as documentation for the .section directive,
= ELF type flags.

Thanks! This s= eems to solve a big part of the issue.

If i= pass =E2=80=9Ccargo:rustc-link-arg=3D-Xlinker=E2=80=9D and =E2=80=9Ccar= go:rustc-link-arg=3D=E2=80=94no-gc-sections=E2=80=9D it does prevent the= linker from removing the probes.

I am stil= l looking for solutions that does not involve explicit involvement of th= e flags by the crate consumer, and maybe something not turning gc off en= tirely but this is a great progress.

--10660d8e775940ae9e59aa67b16a4e69--