Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757062AbYLPWN7 (ORCPT ); Tue, 16 Dec 2008 17:13:59 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752702AbYLPWNr (ORCPT ); Tue, 16 Dec 2008 17:13:47 -0500 Received: from qw-out-2122.google.com ([74.125.92.24]:59627 "EHLO qw-out-2122.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752682AbYLPWNp convert rfc822-to-8bit (ORCPT ); Tue, 16 Dec 2008 17:13:45 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=RRKsU3q8Qk7Qnp0TF6+CYWBnihrrsdtRRf2AlY18V/jopjMLczdumYwkxXKoZ4HqqZ P+8kp8xZprMev6HMy64YepAwVeJebC7GmmJIle0dcN35APJ9QLaT1oaphiFGRZ50RZNU T7EN3aQ9zlEETeYYG0TQFveyFfcLnVY/1/1fw= Message-ID: Date: Tue, 16 Dec 2008 23:13:44 +0100 From: "=?ISO-8859-1?Q?Fr=E9d=E9ric_Weisbecker?=" To: "Ingo Molnar" Subject: Re: [PATCH][RFC 2/23]: SCST core Cc: "Vladislav Bolkhovitin" , "Steven Rostedt" , "Sam Ravnborg" , linux-scsi@vger.kernel.org, "James Bottomley" , "Andrew Morton" , "FUJITA Tomonori" , "Mike Christie" , "Jeff Garzik" , "Boaz Harrosh" , "Linus Torvalds" , linux-kernel@vger.kernel.org, scst-devel@lists.sourceforge.net, "Bart Van Assche" , "Nicholas A. Bellinger" In-Reply-To: <20081216214926.GU14787@elte.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Disposition: inline References: <494009D7.4020602@vlnb.net> <49400ACD.3070502@vlnb.net> <20081210191213.GA15273@uranus.ravnborg.org> <49414DBE.6070801@vlnb.net> <20081211210917.GB27010@uranus.ravnborg.org> <4942BA85.3070408@vlnb.net> <1229118607.24995.18.camel@localhost.localdomain> <4943CAAB.4050008@vlnb.net> <20081216214926.GU14787@elte.hu> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2008/12/16 Ingo Molnar : > > * Fr?d?ric Weisbecker wrote: > >> > All the above functionality is almost what we need. The only thing >> > left, which I forgot to mention, is possibility to log also functions >> > return value on exit. This is what TRACE_EXIT_RES() in SCST does. Is >> > it possible to add those? >> >> I want to add that on the function graph tracer. That can be done pretty >> easily. The only problem comes with the type of the return value. Would >> this tracer be supposed to always return a 64 bits value regardless of >> the real typ of the value? There would be some pointless bytes on most >> return values. I don't know how to proceed for this problem. > > Things like mov ...,%eax are zero-extend so they'll zap the high 32 bits. That's right, but the problem occurs under 32 bits. The return values for 64 bits are in eax and edx. And most of the time, the high part (edx) will be junk. > The real problem are byte return values generated via things like: > > movb $1, %al > > those wont zero-extend, so you could get garbage in the output. One > approach would be to try a quick hack just to see how common a problem > this is. Yes, I will try something. > We could extract the return type from the debuginfo, hash it in a > read-mostly table and then look it up, but that seems complex both in > terms of build overhead and in terms of runtime overhead. I thought about it too and as you say it's rather complex. And thinking about non primitive types (like pid_t....) that would require a second pass of analysis to retrieve the corresponding primitive... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/