Re: HP catchpoint code

[Daniel Jacobowitz <drow@mvista.com>]

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