From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 01:09:51 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E13E71065674; Wed, 9 Nov 2011 01:09:51 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 188438FC0A; Wed, 9 Nov 2011 01:09:50 +0000 (UTC) Received: by wyg36 with SMTP id 36so1545641wyg.13 for ; Tue, 08 Nov 2011 17:09:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y805aaeyJH6ng0OJ+OqaLwirMzODHxaYByQOSdEQTUY=; b=W5J5eHg4kzkBVRB5MNkv7N88uceUycZQKhAzekTZA8zje35IH3/72OwrylI1GQjD9m 9OA2ZkMoxi9RlVqkDj5nA0JSuVIT1LgGUhzFwfIOgcWq3EMyFR+DZoGYIBhpRRl1yYpK mOFmdYJCCm3AETit4y2l1TvMIHdbrh0POB/JI= MIME-Version: 1.0 Received: by 10.180.101.97 with SMTP id ff1mr213593wib.42.1320800990008; Tue, 08 Nov 2011 17:09:50 -0800 (PST) Received: by 10.180.81.200 with HTTP; Tue, 8 Nov 2011 17:09:49 -0800 (PST) In-Reply-To: <4EB9975F.4090601@FreeBSD.org> References: <4EB9975F.4090601@FreeBSD.org> Date: Tue, 8 Nov 2011 20:09:49 -0500 Message-ID: From: Arnaud Lacombe To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: Attilio Rao , freebsd-current@freebsd.org Subject: Re: Using Instruction Pointer address in debug interfaces [Was: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 01:09:52 -0000 Hi, On Tue, Nov 8, 2011 at 3:55 PM, Andriy Gapon wrote: > > [cc list trimmed] > > on 08/11/2011 22:34 Attilio Rao said the following: >> 2011/11/8 Arnaud Lacombe : >>> To avoid future complaints about the fact that I would be only "talk" >>> without "action", I did implement what I suggested above. As it is >>> quite a large patch-set, I will not post it directly here, however, it >>> is available on github: >> >> I really think that this is way too dependent by the good health of >> your tool, thus that is highly fragile. >> >> However, you may have more luck by just the core of your kernel >> changes here, for comment and leave alone all the (ptr -> >> LOCK_FILE/LOCK_LINE conversion). >> >> Said that, I think this logic is too fragile and likely won't be as >> effective as __FILE__/__LINE__ in many cases. > > I agree. > If we were able to somehow automatically, magically, easily and correctly > determine an instruction pointer of a caller, then it would make sense to ditch > explicit passing of __FILE__/__LINE__ arguments in favor of doing instruction > pointer decoding. > again, no need for magic, this already exists, as the form of gcc[0]'s __builtin_return_address(0). > But if we are just replacing explicit passing of (well-known) macros > __FILE__/__LINE__ with explicit passing of THIS_IP, then I don't see a point. > make sense too, but you need to be sure stuff between the caller and callee is fully inlined. > Apologies if I missed the rationale for this change. > mostly getting rid of all the __FILE__ and __LINE__ bloat. - Arnaud [0]: check about LLVM support is left to the reader.