From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26038 invoked by alias); 12 Sep 2005 21:48:38 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 26018 invoked by uid 22791); 12 Sep 2005 21:48:31 -0000 Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 12 Sep 2005 21:48:31 +0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.4/8.13.4) with ESMTP id j8CLlv9M010209; Mon, 12 Sep 2005 23:47:57 +0200 (CEST) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.4/8.13.3) with ESMTP id j8CLlv8G022329; Mon, 12 Sep 2005 23:47:57 +0200 (CEST) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.4/8.13.4/Submit) id j8CLluXQ011168; Mon, 12 Sep 2005 23:47:56 +0200 (CEST) Date: Mon, 12 Sep 2005 21:48:00 -0000 Message-Id: <200509122147.j8CLluXQ011168@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: drow@false.org CC: gdb-patches@sourceware.org In-reply-to: <20050909212825.GA9449@nevyn.them.org> (message from Daniel Jacobowitz on Fri, 9 Sep 2005 17:28:26 -0400) Subject: Re: [RFC] Tighten and tweak ptrace argument checks References: <20050909212825.GA9449@nevyn.them.org> X-SW-Source: 2005-09/txt/msg00094.txt.bz2 > Date: Fri, 9 Sep 2005 17:28:26 -0400 > From: Daniel Jacobowitz > > Hi Mark, > > I discovered recently that your rewrite of the ptrace argument type > checks had busted some (not-yet-contributed, sorry) changes to use long > long for ptrace calls on MIPS n32. > > This made me take a closer look at the tests. It turns out that > neither the return type checks nor argument type checks work on > GNU/Linux. The return type check will work with oldish versions of > GCC, but not with 4.0 (or 3.4, I think). The argument type checks > won't work at all. Here's the problem: > > extern long int ptrace (enum __ptrace_request, ...); > > () won't match ...; this is important because of different calling > conventions on some platforms. It's always been my understanding that the the varargs stuff was used because the number of arguments is actually dependent on the request. It allows you to leave off any unused arguments instead of providing a summy value like what's been done traditionally. Bear in mind that varargs functions only really work with word-sized arguments. Otherwise you'll find yourself on a slippery slope very soon, especially with system calls. Anyway, the varargs stuff is a major nightmare, because different versions of GCC treat the prototypes very differently. That's why I included a sane default. > On i386-pc-linux-gnu the defaults work so this is merely an annoyance. > When the real type is long long instead of long, well, it wasn't > pretty... But 'long long' as a return type or argument type really doesn't make sense for ptrace(2). But then of course MIPS doesn't make any sense either, so that's perfectly fine ;-). > So here's a proposed patch. It handles the GNU/Linux case. It handles > long long. It also is violently fatal if it fails, instead of making > up something sensible - this is because I wasted several days trying to > figure out what was wrong with GDB when it was casting all the ptrace > arguments to the wrong type. I'm sure it'll break the build in a lot > of places but I think it's worth fixing if you want to use autoconf for > this at all! Sorry 'bout that, but you've created a ptrace variant that's incompatible with everything else on the planet. All other Linux ports use long. I presume you invented the 'long long' to be able to return 64-bit register values with PTRACE_PEEKUSER. That interface should really die, and be replaced with PTRACE_GETREGS and friends. > Any comments on the patch? Sorry, yes, I'm almost certain this will break on OSF/1 or AIX or HP-UX. It'll probably break even for Linux if you're using an older compiler. I think it'd be better to explicitly check for the Linux varargs-with-enum type prototype. Give me a few days, and I'll try to come up with something better. > I also noticed considerable PTRACE_ARG3_TYPE vs PTRACE_TYPE_ARG3 > confusion in the sources. I think that the last time I looked at this, > I convinced myself that it was possible to get them out of sync, and > the results would be pretty gruesome. I didn't touch that for now. This is because there are several ports that are basically unmaintained; nobody feels responsible enough to keep them up to date. Mark