Re: HP catchpoint code

[Daniel Jacobowitz <drow at mvista dot com>]

On Mon, Oct 21, 2002 at 11:10:41AM -0400, Andrew Cagney wrote:
> >On Tue, Aug 13, 2002 at 05:59:44PM -0400, Andrew Cagney wrote:
> >
> >>I don't think we can start writing the PA obituary just yet.
> >>
> >>Something to-the-point is probably in order as part of the 5.3 
> >>announcement.
> >
> >
> >You're right.  But we can write the obituary on some of its
> >catchpoints, I think.
> >
> >For lack of an HP/UX maintainer, I'd like to disable fork/vfork/exec
> >catchpoints and following on HP/UX.  This is a necessary first step in
> >submitting the GNU/Linux version of these features; because I want it
> >to work for both local and remote debugging, I had to segment it
> >somewhat differently.
> >
> >I'd also like to kill the clone_and_follow_inferior code, which was
> >never really functional; the switch is commented out with a reference
> >to an HP/UX 10.20 bug.  We don't have the infrastructure to debug two
> >processes at once right now, anyway; and we don't have a general way to
> >clone the debugger and get a second terminal.
> >
> >Unless someone has an objection, I'll submit a patch to do this on
> >Monday.
> 
> (Everything on the internet takes a week :-)
> 
> Wouldn't it be possible to HP/UX ify the existing code and then persue 
> the new in parallel? (eg  LOC_HP_THREAD_LOCAL_STATIC).
> 
> I think the code base is otherwize exposed to the problem of having the 
> existing functionality removed without having the new code in place. 
> Once the new framework is working I think you're in a stronger position 
> to argue for the removal of that old code.

Well, I could do this.  If the code that's there now were for a
supported target, I'd agree it was the way to go.  But it's for an
_unmaintained_ target, and one that historically no one has been
willing to take care of.  And I managed to kill an awful lot of
confusing junk in the supposedly platform-independent infrun code when
I knifed it in my working tree.  The logic makes much more sense now. 
Yes, I removed some hacks which may be necessary on HP/UX for this
feature to work; but at the same time they belong in HP-specific code,
and they could probably be implemented in a cleaner fashion, and if
someone wants to resupport this platform latter I'm willing to work
with them to find less intrusive ways to do it.

I think that arguing for the removal of a feature which only works on a
platform that no one maintains, and that often doesn't even build, is a
pretty strong position to begin with.

This is where I argue again that we should just remove the HP/UX code
and be done with it, since no one is willing to care for it properly -
certainly I'm not, without even access to an HP/UX system.  As C++
maintainer I even asked on the list several times for access to an HP
system or testing on one, and couldn't find a volunteer for either.
And carrying around the burden of this code makes working on supported
platforms much more awkward.


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.


Does anyone else have an opinion?  If the consensus is that I'm out of
line, I guess it's time to go back to an older working tree and start
renaming...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer