HP catchpoint code

HP catchpoint code

[Daniel Jacobowitz]

I'm working on GNU/Linux support for fork and exec catchpoints.  The kernel
code I needed (well, wanted; it's possible without, just bloody awkward) was
straightforward, and I already have strace using it.  When I started digging
into the GDB code for it I got a little quagmired, though.

My plan is to completely ignore the existing support for this feature.  An
astute code reviewer will note that it doesn't work anywhere but HP/UX; the
code to initialize it is only present for ttrace.  The target-independent
portions of it are completely dependent on the ttrace model.  I'd like to
rename, or at least recomment, TARGET_WAITKIND_FORKED (and VFORKED, possibly
EXECD, haven't gotten to that one yet) to indicate their HP-specificness and
add some new waitkinds for the different model I'm using.  Any objections?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: HP catchpoint code

[Jim Blandy]

Daniel Jacobowitz <drow@mvista.com> writes:
> I'm working on GNU/Linux support for fork and exec catchpoints.  The kernel
> code I needed (well, wanted; it's possible without, just bloody awkward) was
> straightforward, and I already have strace using it.  When I started digging
> into the GDB code for it I got a little quagmired, though.
> 
> My plan is to completely ignore the existing support for this feature.  An
> astute code reviewer will note that it doesn't work anywhere but HP/UX; the
> code to initialize it is only present for ttrace.  The target-independent
> portions of it are completely dependent on the ttrace model.  I'd like to
> rename, or at least recomment, TARGET_WAITKIND_FORKED (and VFORKED, possibly
> EXECD, haven't gotten to that one yet) to indicate their HP-specificness and
> add some new waitkinds for the different model I'm using.  Any objections?

Those were introduced by TIHPM; I gather that HP designed them with
the intention of doing things right --- generic mechanisms built on an
HP-specific layer --- but they never discussed the design with the
rest of the GDB scene, and the supposedly generic stuff didn't end up
as generic as it should have been.

(To be fair, I think HP did the work in the Old Bad Days, when `the
rest of the GDB scene' was a private list within Cygnus.  There was a
public list, but it wasn't very active --- who wants to have a design
discussion in a forum where there is clearly nothing going on?)

I'm uncomfortable just renaming the old stuff and moving on --- if
we're going to replace it with something better, I'd like to have some
plan for eventually getting rid of the old stuff altogether.  For
example, would it make sense to set a deadline by which the old stuff
would go away?  It looks like the PA, and thus ttrace, is scheduled to
be obsoleted; we could obsolete the old catchpoint stuff at that
point, too, without repercussions beyond what the obsoleting will
cause by itself.

Could you talk more about the new catchpoint implementation you have
in mind?  (Maybe you did and I missed it --- sorry if so.)

Re: HP catchpoint code

[Daniel Jacobowitz]

On Tue, Aug 13, 2002 at 03:39:59PM -0500, Jim Blandy wrote:
> 
> Daniel Jacobowitz <drow@mvista.com> writes:
> > I'm working on GNU/Linux support for fork and exec catchpoints.  The kernel
> > code I needed (well, wanted; it's possible without, just bloody awkward) was
> > straightforward, and I already have strace using it.  When I started digging
> > into the GDB code for it I got a little quagmired, though.
> > 
> > My plan is to completely ignore the existing support for this feature.  An
> > astute code reviewer will note that it doesn't work anywhere but HP/UX; the
> > code to initialize it is only present for ttrace.  The target-independent
> > portions of it are completely dependent on the ttrace model.  I'd like to
> > rename, or at least recomment, TARGET_WAITKIND_FORKED (and VFORKED, possibly
> > EXECD, haven't gotten to that one yet) to indicate their HP-specificness and
> > add some new waitkinds for the different model I'm using.  Any objections?
> 
> Those were introduced by TIHPM; I gather that HP designed them with
> the intention of doing things right --- generic mechanisms built on an
> HP-specific layer --- but they never discussed the design with the
> rest of the GDB scene, and the supposedly generic stuff didn't end up
> as generic as it should have been.
> 
> (To be fair, I think HP did the work in the Old Bad Days, when `the
> rest of the GDB scene' was a private list within Cygnus.  There was a
> public list, but it wasn't very active --- who wants to have a design
> discussion in a forum where there is clearly nothing going on?)
> 
> I'm uncomfortable just renaming the old stuff and moving on --- if
> we're going to replace it with something better, I'd like to have some
> plan for eventually getting rid of the old stuff altogether.  For
> example, would it make sense to set a deadline by which the old stuff
> would go away?  It looks like the PA, and thus ttrace, is scheduled to
> be obsoleted; we could obsolete the old catchpoint stuff at that
> point, too, without repercussions beyond what the obsoleting will
> cause by itself.
> Could you talk more about the new catchpoint implementation you have
> in mind?  (Maybe you did and I missed it --- sorry if so.)

When I posted that, I was neck-deep implementing the kernel code to
support the new interface.  It turned out rather different than I
expected!  I'll still need some changes, but not as many as I feared,
so I'm reusing the code that's there.

I'm almost (not quite) intrigued enough to investigate the HP
mechanisms; they made some bizarre decisions in the implementation and
I can't figure out why.  For instance, in when breakpoints are detached
when following vforks.  In GNU/Linux you need the breakpoints removed
while the vfork is running, no matter which process you're following. 
Either you follow the parent, and you have to remove breakpoints until
the exec happens (which means you must hold on to the child until it
execs!).  Or you follow the child, in which case you can't resume the
parent until the child has exec'd anyway, and you need to detach
breakpoints from it before resuming it.  That's where most of my
pain is coming from right now.

So let's plan to hold on to it for now.  I may strip out some of its
complexity after the PA is obsoleted, if no one expresses interest in
reviving that port in a pretty timely fashion.  I can't fix bugs in
something that makes no sense to me :)

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: HP catchpoint code

[Andrew Cagney]

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.

Andrew

Re: HP catchpoint code

[Carlos O'Donell]

> 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.
> Andrew

When you say 'remove PA' you don't _really_ mean remove PARISC support
from gdb? :}

c.

Re: HP catchpoint code

[Daniel Jacobowitz]

On Wed, Aug 14, 2002 at 10:04:28AM -0400, Carlos O'Donell 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.
> > Andrew
> 
> When you say 'remove PA' you don't _really_ mean remove PARISC support
> from gdb? :}

Absolutely.  It's gotten (started?) very crufty, and _no one_ has been
willing to maintain it.  I know ye HPPA/Linux folks have your own port,
and so far not a soul has been willing to contribute it to GDB - I
don't know who can, I sure didn't write it, I just include it in the
Debian packages to make Randolph stop nagging me :)

More to the point, though - if someone steps forward to do some
long-needed work on PARISC, that can stay, but HP/UX support is what I
really want to leave (or be updated).

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: HP catchpoint code

[Carlos O'Donell]

> 
> Absolutely.  It's gotten (started?) very crufty, and _no one_ has been
> willing to maintain it.  I know ye HPPA/Linux folks have your own port,
> and so far not a soul has been willing to contribute it to GDB - I
> don't know who can, I sure didn't write it, I just include it in the
> Debian packages to make Randolph stop nagging me :)
> 
> More to the point, though - if someone steps forward to do some
> long-needed work on PARISC, that can stay, but HP/UX support is what I
> really want to leave (or be updated).
> 

I can't plead ignorance on the issue since Matthew Wilcox mentioned 
that GDB wanted to drop PARISC support... and the main reason I'm on this
list, and others, is to keep a finger on the pulse of PARISC specific 
problems across the board from binutils/gcc/glibc/gdb.

I'll step forward to do PARISC support for GDB.
These may be my famous last words ;)

AFAIK the issues revolve around some final FSF paperwork that Alan Modra
needs to complete to get the debian .dpatch's accepted upstream? All of 
our modifications to gdb are in the debian package as patches. We do have
a gdb cvs tree, but that is based on Randolph's 5.1 merge. I will get 
this up to date as soon as possible.

As for new development, and moving forward with PARISC (HP/UX support?)
that will take my time, research and development. Not to mention more
gdb source digging... 

c.

Re: HP catchpoint code

[Andrew Cagney]

>> 
>> Absolutely.  It's gotten (started?) very crufty, and _no one_ has been
>> willing to maintain it.  I know ye HPPA/Linux folks have your own port,
>> and so far not a soul has been willing to contribute it to GDB - I
>> don't know who can, I sure didn't write it, I just include it in the
>> Debian packages to make Randolph stop nagging me :)
>> 
>> More to the point, though - if someone steps forward to do some
>> long-needed work on PARISC, that can stay, but HP/UX support is what I
>> really want to leave (or be updated).
>> 
> 
> 
> I can't plead ignorance on the issue since Matthew Wilcox mentioned 
> that GDB wanted to drop PARISC support... and the main reason I'm on this
> list, and others, is to keep a finger on the pulse of PARISC specific 
> problems across the board from binutils/gcc/glibc/gdb.
> 
> I'll step forward to do PARISC support for GDB.
> These may be my famous last words ;)

Ok, the first step is ``write after approval''.  Per the MAINTAINERS 
file:  ``To get recommended for the Write After Approval list you need a 
valid FSF assignment and have submitted one good patch.''

Since the PA risc target isn't maintained, its commit rules are more lax 
then for maintained targets.

enjoy,
Andrew

Re: HP catchpoint code

[Carlos O'Donell]

> 
> Ok, the first step is ``write after approval''.  Per the MAINTAINERS 
> file:  ``To get recommended for the Write After Approval list you need a 
> valid FSF assignment and have submitted one good patch.''
> 
> Since the PA risc target isn't maintained, its commit rules are more lax 
> then for maintained targets.
> 
> enjoy,
> Andrew
> 

Andrew,

Understood. Since I'm not a maintainer of any GNU package, I don't have
a GNU account. Would I be able to get a copy of the latest:
'/gd/gnuorg/request-assign.future'?

I'll wrangle out one good patch by cleaning up the "Don't show sr0" 
display changes for disassemblies under PA. The rest will come as I get
up to speed on things.

Thanks for the support :)

Cheers,
Carlos.

Re: HP catchpoint code

[Daniel Jacobowitz]

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.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: HP catchpoint code

[Andrew Cagney]

> 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.

enjoy,
Andrew

Re: HP catchpoint code

[Daniel Jacobowitz]

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

Re: HP catchpoint code

[Andrew Cagney]

As an aside, HP provides (or provided) a testdrive program, see:
   http://www.testdrive.compaq.com/faq
I don't know about the compilers that are installed though - it appears 
that, yet again, a chunk of the Internet just disappeared ... :-/

Andrew

Re: HP catchpoint code

[Daniel Jacobowitz]

On Mon, Oct 21, 2002 at 12:15:38PM -0400, Andrew Cagney wrote:
> As an aside, HP provides (or provided) a testdrive program, see:
>   http://www.testdrive.compaq.com/faq
> I don't know about the compilers that are installed though - it appears 
> that, yet again, a chunk of the Internet just disappeared ... :-/

That makes two test drive programs they provide which won't help:
#

Our systems run versions of HP Tru64 Unix, HP OpenVMS, Red Hat® Linux,
SuSE Linux, TurboLinux, FreeBSD, Debian Linux, Microsoft Windows 2000,
and Microsoft Windows NT. For more details, take a look under the
Operating Systems section below.


<end quote>

This is a formerly Compaq program; it doesn't cover the PA.  Similarly
the other test drive program covers another OS (MVE?) and offers HP/UX
only for developing conversion utilities.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: HP catchpoint code

[Andrew Cagney]

> On Mon, Oct 21, 2002 at 12:15:38PM -0400, Andrew Cagney wrote:
> 
>> As an aside, HP provides (or provided) a testdrive program, see:
>>   http://www.testdrive.compaq.com/faq
>> I don't know about the compilers that are installed though - it appears 
>> that, yet again, a chunk of the Internet just disappeared ... :-/
> 
> 
> That makes two test drive programs they provide which won't help:
> #
> 
> Our systems run versions of HP Tru64 Unix, HP OpenVMS, Red Hat® Linux,
> SuSE Linux, TurboLinux, FreeBSD, Debian Linux, Microsoft Windows 2000,
> and Microsoft Windows NT. For more details, take a look under the
> Operating Systems section below.
> 
> 
> <end quote>
> 
> This is a formerly Compaq program; it doesn't cover the PA.  Similarly
> the other test drive program covers another OS (MVE?) and offers HP/UX
> only for developing conversion utilities.

The above message is wrong.  The reason I can't get at the h/w is:

http://www.testdrive.compaq.com/news/
October 21, 2002    As a reminder, the HP Test Drive Program is moving 
to a new lab. We will be down the week of October 23, and expect to have 
service restored the week of the 30th. During this time, our systems 
will be unavailable and registration will be disabled. Note: As a 
courtesy to our existing users, we are leaving spe147 up as long as 
possible with /house mounted read-only so they can access their files.

enjoy,
Andrew

Re: HP catchpoint code

[Andrew Cagney]

> 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.

> 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...

No, but someone did blink :-)

Andrew

Re: HP catchpoint code

[Daniel Jacobowitz]

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