From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1260 invoked by alias); 4 Jan 2006 17:40:22 -0000 Received: (qmail 1250 invoked by uid 22791); 4 Jan 2006 17:40:22 -0000 X-Spam-Check-By: sourceware.org Received: from smtp11.wanadoo.fr (HELO smtp11.wanadoo.fr) (193.252.22.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 04 Jan 2006 17:40:19 +0000 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf1108.wanadoo.fr (SMTP Server) with ESMTP id 18D671C001FF for ; Wed, 4 Jan 2006 18:40:17 +0100 (CET) Received: from takamaka.act-europe.fr (AStDenis-105-1-15-254.w81-248.abo.wanadoo.fr [81.248.212.254]) by mwinf1108.wanadoo.fr (SMTP Server) with ESMTP id 64D021C0017A for ; Wed, 4 Jan 2006 18:40:16 +0100 (CET) X-ME-UUID: 20060104174016413.64D021C0017A@mwinf1108.wanadoo.fr Received: by takamaka.act-europe.fr (Postfix, from userid 507) id B377C47E79; Wed, 4 Jan 2006 21:40:09 +0400 (RET) Date: Wed, 04 Jan 2006 17:40:00 -0000 From: Joel Brobecker To: gdb-patches@sources.redhat.com Subject: How to implement gcore on pa-hpux ? Message-ID: <20060104174009.GC1868@adacore.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="lEGEL1/lMxI0MVQ2" Content-Disposition: inline User-Agent: Mutt/1.4i 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/msg00042.txt.bz2 --lEGEL1/lMxI0MVQ2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 1583 Hello, I have implemented the gcore command on pa-hpux for one of our customers. I would like to contribute this work, but I know that for sure the approach is took is not acceptable. The work is based on using the TT_PROC_CORE ttrace command: TT_PROC_CORE This request causes the traced process to generate a core file in the target process's current working directory. The core file is named core.pid where pid is the process ID of the target process. The process's state is left unchanged. The lwpid, addr, data and addr2 arguments must be zero. So I created a new function in infttrace.c. In order to avoid re-writing the part of gcore.c that add the command, and handles the arguments of this command, I simply hooked the new infttrace directly into the gcore code. A bit crude, but it works and it's pretty localized. For the FSF tree, I'd like to implement this a little better, and it seems to me that the core part of this command, the part that actually creates the core file, should be a method of some vector. But which vector? The way the gcore command is currently written, it seems that it would make sense for it to be part of the target vector. No? However, in the case of HP/UX, there is a slight complication, because the method is only good in the native case... Any suggestion? Attached is the infttrace function that creates the core dump. It is largely inspired from the HP WDB debugger sources (contributed recently). Thanks, -- Joel --lEGEL1/lMxI0MVQ2 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dcf.c" Content-length: 1156 void dump_core_file (int pid, const char *filename) { int tt_status; char buf[64]; tt_status = call_ttrace (TT_PROC_CORE, pid, (TTRACE_ARG_TYPE) filename, 0, 0); if (tt_status == -1) { /* With some versions of HP/UX, specifying the name of the core file is not supported, so this may have been the cause for this failure. Try again without the file name. */ tt_status = call_ttrace (TT_PROC_CORE, pid, 0, 0, 0); if (tt_status != -1) { /* Success, so indeed the filename was the source of the problem. Inform the user that the core file was named differently (if indeed the filename is different from the default core file name!) */ sprintf (buf, "core.%d", pid); if (strcmp (filename, buf) != 0) { warning ("The Operating System does not allow the dump in %s", filename); filename = buf; } } } if (tt_status == -1) perror_with_name ("ttrace:"); else fprintf_filtered (gdb_stdout, "Saved corefile %s\n", filename); } --lEGEL1/lMxI0MVQ2--