From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8897 invoked by alias); 12 Jan 2006 20:44:27 -0000 Received: (qmail 8889 invoked by uid 22791); 12 Jan 2006 20:44:26 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 12 Jan 2006 20:44:24 +0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.4/8.13.4) with ESMTP id k0CKiE4p004672; Thu, 12 Jan 2006 21:44:14 +0100 (CET) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.4/8.13.3) with ESMTP id k0CKiEiN022949; Thu, 12 Jan 2006 21:44:14 +0100 (CET) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.4/8.13.4/Submit) id k0CKiCBC018804; Thu, 12 Jan 2006 21:44:12 +0100 (CET) Date: Thu, 12 Jan 2006 20:44:00 -0000 Message-Id: <200601122044.k0CKiCBC018804@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: brobecker@adacore.com CC: gdb-patches@sources.redhat.com In-reply-to: <20060112055529.GJ676@adacore.com> (message from Joel Brobecker on Thu, 12 Jan 2006 09:55:29 +0400) Subject: Re: [RFA] implement gcore on hp/ux References: <20060110171752.GL925@adacore.com> <200601102029.k0AKTfPh011880@elgar.sibelius.xs4all.nl> <20060112055529.GJ676@adacore.com> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00130.txt.bz2 > Date: Thu, 12 Jan 2006 09:55:29 +0400 > From: Joel Brobecker > > 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