This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] implement gcore on hp/ux
> Date: Thu, 12 Jan 2006 09:55:29 +0400
> From: 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.
Heh, s390/s390 is Linux, so you can drop it from that list. So in
fact all the above targets, use procfs. Now the problem is that there
are a few configurations that you don't mention above that use procfs
too. It wouldn't suprise me at all if most of them would support the
gcore functionality, although OSF/1 probably needs some tweaks since
it doesn't use ELF as its executable format.
> 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.
What do you mean by "never pushed on the target stack"? There are
push_target() calls in inf-ptrace.c
> 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.
We've made such hacks too often in the past. In fact those hacks
largely are why you're having so much trouble now.
> 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?
That's exactly what needs to be done. Unfortunately npbody seems to
care enough about the targets using procfs to do the actual work.
> I'm sure we can find ways to scrub directly inside the procfs
> target vector, but this would seem rather ugly to me.
Agreed.
> 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.
That'd certainly be appreciated.
Mark