Re: [RFA] implement gcore on hp/ux

[Joel Brobecker <brobecker@adacore.com>]

Mark,

> I'm not sure I like the exec_set_write_core_file() hack.  Targets
> should really do this the proper way, initializing their target vector
> properly.  Can't you get rid of it by setting to_write_core_file in
> procfs.c:init_ptoc_ops() and linux-nat.c:linux_target()?

I ran into something I didn't expect. Doing the above for all linux
targets was easy; so was it for all freebsd targets. But I still have
to work on the following ones (names of mh files):
  . i386/i386sol2
  . i386/sol2-64
  . sparc/sol2
  . i386/i386v42mp
  . s390/s390
All the above configurations currently include gcore.

I started working on i386sol2, and found out that the target vector
for this configuration seems to be the procfs one. In the rest of
this discussion, I will refer to "the" target vector as the one at
the process stratum.

For Linux and FreeBSD, it was easy because the nat files were always
creating their own target vector based on the ptrace one. The ptrace
target vector was never pushed on the target stack.

However, so far, the procfs target vector IS pushed on the target
stack, and no modification has been needed so far. But if we are
to continue in this direction, we will need to be able to modify
this target vector.

I was less and less convinced by the entire idea of using the target
vector, at least for such a minor extension to GDB just for HP/UX.
Perhaps a few lines of code duplication in inf-ttrace wouldn't be
so bad.

Except that it might be a good general cleanup for GDB. For instance,
I really like the model used by Linux for instance, where they use
a default target vector provided by inf-ptrace, and tailor it to
their needs. Would it make sense to modify the procfs support such
that it is no longer pushed itself on the stack, but instead used
as a tailorable template?

I'm sure we can find ways to scrub directly inside the procfs
target vector, but this would seem rather ugly to me.

The whole patch is becoming too big in my opinion to be submitted
in one go. If we agree on continuing on this path, then I will submit
one or more preparatory patches (such as making the procfs target vector
a template for instance), as needed.

Thanks,
-- 
Joel