From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14254 invoked by alias); 14 Oct 2005 22:15:00 -0000 Mailing-List: contact systemtap-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sources.redhat.com Received: (qmail 14235 invoked by uid 22791); 14 Oct 2005 22:14:58 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Jim Keniston Cc: "Frank Ch. Eigler" , Kevin Stafford , SystemTAP Subject: Re: probes that access userspace In-Reply-To: Jim Keniston's message of , 14 October 2005 14:08:50 -0700 <1129324130.2846.10.camel@dyn9047018079.beaverton.ibm.com> X-Shopping-List: (1) Fervent money (2) Historic trash (3) Intransigent livers (4) Ostentatious dyspeptic nutrition polluters Message-Id: <20051014221456.054A3180989@magilla.sf.frob.com> Date: Fri, 14 Oct 2005 22:15:00 -0000 X-SW-Source: 2005-q4/txt/msg00053.txt.bz2 > > No, there appears to be no such qualification data in the debuginfo at > > all. IIRC, the preprocessor makes __user go away before the compiler > > ever sees it. > > That's my understanding as well. It's certainly possible to do a compiler extension to express __user in the DWARF type info. I've considered it, and can discuss it further with the compiler folks. That solution is a long-term prospect--it would be unlikely to happen by GCC 4.1, and might never be backported to compilers like RHEL4's. However, we've also gotten the opinion from at least one kernel developer that relying on __user annotations is still insufficiently paranoid. That is, they might be missing from some kernel source, and so any time you access a pointer you are taking your fate in your own hands since it might be an unannotated user-mode pointer. I'm not sure there is anything more to be done about that concern than state the caveat. Thanks, Roland