From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31633 invoked by alias); 24 Mar 2010 18:28:58 -0000 Received: (qmail 31596 invoked by uid 48); 24 Mar 2010 18:28:48 -0000 Date: Wed, 24 Mar 2010 18:28:00 -0000 Message-ID: <20100324182848.31595.qmail@sourceware.org> From: "prerna at linux dot vnet dot ibm dot com" To: systemtap@sources.redhat.com In-Reply-To: <20100323210435.11424.dsmith@redhat.com> References: <20100323210435.11424.dsmith@redhat.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug translator/11424] dwarfless kprobe.* probes don't validate at translate time X-Bugzilla-Reason: AssignedTo Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2010-q1/txt/msg00767.txt.bz2 ------- Additional Comments From prerna at linux dot vnet dot ibm dot com 2010-03-24 18:28 ------- (In reply to comment #6) > The fact that probes resolve, but might not trigger/register at runtime since > they aren't available then isn't really an error, even in -l/-L mode IMHO. > It would be nicer to give a WARNING that the probe syntax itself is valid, but > might not trigger or register at runtime. Probe syntax gets validated at pass 1 anyway :-) If by probe resolution you mean finding addresses for a supplied symbol argument in the script, this happens only at runtime. In other words, a dwarfless / hardware breakpoint probe gets registered only if the address for supplied name can be decoded, and required resources are available. IMHO the purpose of -l/-L modes is to list all probes with argument symbols matching a given pattern -- which is really not possible to find out at translation stage for such cases. This is why it appears moot for such probe families. -- http://sourceware.org/bugzilla/show_bug.cgi?id=11424 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.