From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19066 invoked by alias); 8 Nov 2002 03:21:40 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 19059 invoked from network); 8 Nov 2002 03:21:39 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 8 Nov 2002 03:21:39 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18A1aZ-0002Qp-00; Thu, 07 Nov 2002 23:21:51 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 189zj6-0001NL-00; Thu, 07 Nov 2002 22:22:32 -0500 Date: Thu, 07 Nov 2002 19:21:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Jim Blandy , gdb@sources.redhat.com Subject: Re: HP catchpoint code Message-ID: <20021108032231.GA4502@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Jim Blandy , gdb@sources.redhat.com References: <20020812153334.GA30891@nevyn.them.org> <20020813214211.GA9735@nevyn.them.org> <3D598150.1000106@ges.redhat.com> <20021018221617.GA4804@nevyn.them.org> <3DB418F1.2050607@redhat.com> <20021021153319.GA23624@nevyn.them.org> <3DCAF62A.2050209@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DCAF62A.2050209@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-11/txt/msg00081.txt.bz2 On Thu, Nov 07, 2002 at 06:24:26PM -0500, Andrew Cagney wrote: > > >In summary, I'd rather yank it; mark the bits in HP-specific files as > >//OBSOLETE; and go on to support this feature on what seems to be a > >more useful and supported platform to GDB's current user and maintainer > >base. > > How many bits of the HP-specific code work at all? > > When someone cuts a branch, a common mistake is to go off and start > doing all sorts of stuff, but never actually finish it. I'm wondering > how much of the code you're looking at falls into that category and can, > as a consequence, simply be yanked. Well, that's a good question :) Joel, could you do me a favor? Run foll-fork.exp and foll-vfork.exp on HP/UX and let me know what the results are. For me, foll-fork.exp passes and foll-vfork.exp refuses to run. On the test system of HP's that I'm using, the test produces: if [istarget "hppa2.0w-hp-hpux*"] { warning "Don't run gdb.base/foll-vfork.exp until JAGaa43495 kernel problem is fixed." return 0 } Simulating the test by hand hangs my session. Even doing it in the shipped version of Wildebeest 3.0 hangs, which is rather surprising to me. So it looks like HP never finished this feature either; perhaps the unpronounceable internal defect was never resolved. Which suggests to me: following fork support does work; following vfork was never finished. I should feel a little guilty if I break following forks and not at all if I break following vforks. Unless someone speaks up I'll try to update my fork patches to support fork on HP/UX and to disable the vfork following. I think Joel was agreeable to this, and he's grudgingly as close as we come to having a port maintainer :) Any preference on ripping out vs. commenting out the code in infrun.c to support the vfork following? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer