From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17621 invoked by alias); 14 Sep 2005 14:43:50 -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 17013 invoked by uid 22791); 14 Sep 2005 14:43:05 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 14 Sep 2005 14:43:05 +0000 Received: from drow by nevyn.them.org with local (Exim 4.52) id 1EFYTX-0005P2-4E; Wed, 14 Sep 2005 10:43:03 -0400 Date: Wed, 14 Sep 2005 14:43:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: gdb-patches@sourceware.org Subject: Re: [RFC] Tighten and tweak ptrace argument checks Message-ID: <20050914144303.GA20354@nevyn.them.org> Mail-Followup-To: Mark Kettenis , gdb-patches@sourceware.org References: <20050909212825.GA9449@nevyn.them.org> <200509122147.j8CLluXQ011168@elgar.sibelius.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200509122147.j8CLluXQ011168@elgar.sibelius.xs4all.nl> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-09/txt/msg00103.txt.bz2 On Mon, Sep 12, 2005 at 11:47:56PM +0200, Mark Kettenis wrote: > > 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. I "invented" the long long in order to: - be compatible with the n64 ptrace interface; the design of n32 Linux is to be compatible with o32 wherever possible, be compatible with n64 where it isn't possible, and discourage n32-specific ABIs. - use PTRACE_PEEKDATA to read n64 data spaces, much as Richard is doing now for ppc64. This is important on multiple-architecture installations. _Constructive_ criticism is welcome. I did this work a long time ago, but never got it merged to either gdb or glibc (just the kernel bits). So if you have an alternate suggestion, I don't feel too bad about making an incompatible change to the kernel ABI here. Ralf probably won't object either. PTRACE_PEEKUSER is not a big deal for this interface; you can return 32-bit chunks of the 64-bit registers. It just requires an n32-specific ABI for ptrace. > > 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. Hmm, you're right - I got the logic backwards. > > 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. I think that you bear some responsibility here, for introducing one without getting rid of the other. It's impossible to keep them straight and there's no obvious difference between them. This sort of unfinished transition is exactly what I remember arguing against when we last discussed "deprecated_*". There's all of five definitions under config/, the default definition in inferior.h, and a couple of uses. I don't see any reason why any of the existing definitions are necessary, so why not just remove them and sed the uses? If there's some particular platform from the bunch that you think would be non-obvious, you could always ask specifically for someone to try it. I can't help with (and don't care about) lynx, but I have access to all the others. The above is for any value of "you". I don't think you, Mark, have an obligation to fix it at this date. -- Daniel Jacobowitz CodeSourcery, LLC