From nobody Mon Jun 24 16:06:20 2024 X-Original-To: dev-commits-src-all@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 4W7CWP0vLcz5P9hj; Mon, 24 Jun 2024 16:06:25 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4W7CWN6CbYz4L1V; Mon, 24 Jun 2024 16:06:24 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-qk1-x72d.google.com with SMTP id af79cd13be357-7960454db4fso322923585a.2; Mon, 24 Jun 2024 09:06:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719245183; x=1719849983; darn=freebsd.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:sender :from:to:cc:subject:date:message-id:reply-to; bh=pnbOVZkjnhseY7yDpNrkyFNd5YOJpR0SnMbw8mNPZOY=; b=B3v5/yBZ9Y9KHI3Ok6U4SGbGNeX0/97JxBGQYYTDZWdAZ6HWWg405jPu/yuG2pcQ69 mMh3EgQEeUmDZL8jojl9bZTu6ld2VhRSLyj2AT+pNVAMx/aqMJDQl1sCQiiCrDNolzav qu173bGGVjbB5Pd/GV6MrPhdwqmis5F+tmJxLg9unIaDFam/qV//4LKQxr0rv4An9TTC 3aRykxnKHsVoyw8NCyx7F54bd8NM+cnewGlLNlF9KhlB59EQe2uybV/mejyi7sFxM5ei EGkJ1xImajuahAAYeI6gE44/AhxVNnnWdrnGIw05r1XwuYSAid90lntk6TjYTc2wKiXJ lXzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719245183; x=1719849983; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:sender :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=pnbOVZkjnhseY7yDpNrkyFNd5YOJpR0SnMbw8mNPZOY=; b=hXAfCLg40MitBYSJFwP5cdZLJ24GgG2TX/3v3oT1apIuX5NQt3dDpiSyQQLgtU0vdn 5+riyNxmeVhvzRZFJHXGGJQUJaetOu64GUzkj7xzWTKbjS5C9Kk31oyL4j0iEGAStRFx 87dEgcP475VIdXCuM0rvtS+KIkbI8BBkL57MQFah3Zor4lcHtYuKTPpX4M/Z6l76H0VK OcXXruHmGSijEpDITy09Jl3G/P4my8if52nFEswZ023CvvwZVqN5ijZ0rErBreo5FNsV LuVGlSe0wHzqJTW1IzMUfQtkuCOMkOvTcy01/IB96iHRv1SVRaRixlX1ufe6hhUqrydX O4lA== X-Forwarded-Encrypted: i=1; AJvYcCVt0ZWXcfHYH0HN0ZHNRN2bqqRTwsRtJe3VAYKzJNRb1wr9xgOuXq4FP9Ut7nyqXrQotpxp/hrLqqmMLx8i3jGSf7kip0Kltnt0wAeCUaC+gPNM1AcFJ64UniZXwsyJWGmHrgeFxMZILxaiseYAI4JJOQ== X-Gm-Message-State: AOJu0YyQ0u3y3xcUi6Vj7etmnpfySPiKd0qcW7OKSN4QhFlKfP96vl6s HleQ8/yqjdzJ8iqgBRCtISHK/s8bSJ6T33ATiUsO57jpgYuDitjMEHFHSOZT X-Google-Smtp-Source: AGHT+IHnaM51t1AiHZ56FSWNqiOc0kEPf7QKMdHQKjrqwNCetpguRgV2p0AiCQLfm0uv8SoAiH9ZFg== X-Received: by 2002:a05:620a:462c:b0:795:5bdf:aaab with SMTP id af79cd13be357-79be0d7b626mr772950885a.55.1719245183304; Mon, 24 Jun 2024 09:06:23 -0700 (PDT) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id af79cd13be357-79bce8b18fbsm327750285a.39.2024.06.24.09.06.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Jun 2024 09:06:22 -0700 (PDT) Date: Mon, 24 Jun 2024 12:06:20 -0400 From: Mark Johnston To: Ryan Libby Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: ddf0ed09bd8f - main - sdt: Implement SDT probes using hot-patching Message-ID: References: <202406192058.45JKwB77036327@gitrepo.freebsd.org> List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-all@freebsd.org Sender: owner-dev-commits-src-all@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4W7CWN6CbYz4L1V On Mon, Jun 24, 2024 at 08:36:55AM -0700, Ryan Libby wrote: > On Wed, Jun 19, 2024 at 1:58 PM Mark Johnston wrote: > > > > The branch main has been updated by markj: > > > > URL: https://cgit.FreeBSD.org/src/commit/?id=ddf0ed09bd8f83677407db36828aca2c10f419c9 > > > > commit ddf0ed09bd8f83677407db36828aca2c10f419c9 > > Author: Mark Johnston > > AuthorDate: 2024-06-19 20:57:09 +0000 > > Commit: Mark Johnston > > CommitDate: 2024-06-19 20:57:41 +0000 > > > > sdt: Implement SDT probes using hot-patching > > > > The idea here is to avoid a memory access and conditional branch per > > probe site. Instead, the probe is represented by an "unreachable" > > unconditional function call. asm goto is used to store the address of > > the probe site (represented by a no-op sled) and the address of the > > function call into a tracepoint record. Each SDT probe carries a list > > of tracepoints. > > Questions out of curiosity and maybe ignorance: > > How does this work with relocations? Something must be adjusting these > addresses? The compiler handles this as part of the implementation of asm goto: the inline assembly can reference jump targets with "%l" and they're specified as operands to the asm goto statement. In the kernel these references are resolved statically, and kernel modules will contain relocations for the sdt_tracepoint_set section. > > +/* > > + * Work around an apparent clang bug or limitation which prevents the use of the > > + * "i" (immediate) constraint with the probe structure. > > + */ > > +#define _SDT_ASM_PROBE_CONSTRAINT "Ws" > > +#define _SDT_ASM_PROBE_OPERAND "p" > > Is it because i386 kmods are built with -fPIC? I suspect that that's related, yeah. The compiler might be assuming that some indirection is needed to compute the target address, but in this case it's an address in the same function and presumably can safely be assumed to be an immediate. > By the way, it seems gcc13 (latest in ports) doesn't support the "Ws" > constraint. It seems to have been added to gcc 14. I know i386 is tier > 2 these days, and gcc is a second consideration anyway. Trying to test > out a patch for i386 gcc, I found that it doesn't build currently and > this is one of a few reasons. What happens if "i" is used with gcc? IIRC I had tried gcc+i386 when testing the patch but the kernel failed to build for other reasons at the time.