From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 56125 invoked by alias); 20 Jan 2016 03:07:37 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 56040 invoked by uid 89); 20 Jan 2016 03:07:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1363 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-pa0-f49.google.com Received: from mail-pa0-f49.google.com (HELO mail-pa0-f49.google.com) (209.85.220.49) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 20 Jan 2016 03:07:29 +0000 Received: by mail-pa0-f49.google.com with SMTP id cy9so462226163pac.0; Tue, 19 Jan 2016 19:07:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=/U417rPGD4zamS79izpCg0bjT8B3Kvt0SLj2JMs/HsE=; b=QJp6JE7JBreG+9xC2fBm/N86jy/J1NJOGxEbXTlGqy7QFOf+tuC0PgOhNCHSCvft/Y 8ermOdmUmTBanVoIDnbHbPRDAoaO9ccC3Z2D8HsfJRlMmwMhy7568pdGRWUAbtrUeMiL VNB4y8iqmTXZr4ugsZJsEBsrlONhs9id0gP0KA2dvp7alOp4en6w9mbXmu9uVR+WCG5r 9RfshsqeHiOJ5f+JAZJX8ztg8YuFn8/yk4J3w7csaprvnQTTaRkbg5v2qM6CteyoUn1B kL0zvZHwlImc0iXAcYa0wR8V9JK49kTQ8WzVfAiSSTJxZVPXdLSaeuHE/9Cev8yfWWTW kpFQ== X-Gm-Message-State: ALoCoQmFffzcoHMR7O+RrZ9db9gz39v21muJMHdwFHl7XejRmArqaxkAZyaBP5DZUEn2ehKDW05U4n5YxauI+Y85RNlsMmk9UA== X-Received: by 10.66.100.163 with SMTP id ez3mr49624097pab.5.1453259247158; Tue, 19 Jan 2016 19:07:27 -0800 (PST) Received: from bubble.grove.modra.org (CPE-58-160-163-67.gqzg1.fli.bigpond.net.au. [58.160.163.67]) by smtp.gmail.com with ESMTPSA id qz9sm44850422pab.39.2016.01.19.19.07.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jan 2016 19:07:25 -0800 (PST) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 21D8FEA017A; Wed, 20 Jan 2016 13:37:21 +1030 (ACDT) Date: Wed, 20 Jan 2016 03:07:00 -0000 From: Alan Modra To: Pedro Alves Cc: "H.J. Lu" , John Baldwin , Ulrich Weigand , Binutils , GDB Subject: Re: Are ppc*_elf_write_core_note Os-specific? Message-ID: <20160120030720.GE17028@bubble.grove.modra.org> References: <1736699.V7zq9VJIrx@ralph.baldwin.cx> <1866442.mSXmZIT7y1@ralph.baldwin.cx> <1502134.K9IMtmAub2@ralph.baldwin.cx> <569EA298.8070303@redhat.com> <569EBE31.9070902@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <569EBE31.9070902@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2016-01/txt/msg00042.txt.bz2 On Tue, Jan 19, 2016 at 10:52:33PM +0000, Pedro Alves wrote: > I think that ideally we'd give the same treatment to > elfcore_write_prstatus; it's just that nobody ever did the leg work. Some leg work. For all linux targets except mips n32 which has a 64-bit pr_sigpend and pr_sighold, we have struct elf_prstatus { struct elf_siginfo pr_info; short int pr_cursig; unsigned long int pr_sigpend; unsigned long int pr_sighold; __pid_t pr_pid; __pid_t pr_ppid; __pid_t pr_pgrp; __pid_t pr_sid; struct timeval pr_utime; struct timeval pr_stime; struct timeval pr_cutime; struct timeval pr_cstime; elf_gregset_t pr_reg; int pr_fpvalid; }; struct elf_siginfo is three ints, struct timeval is two longs except for sparc where tv_usec is an int, __pid_t is an int. elf_gregset_t of course varies. Unless I'm missing some odd target struct alignment rule, I think that means linux needs a 32-bit and 64-bit variant of elfcore_write_linux_prprstatus with parameters similar to elfcore_write_linux_prpsinfo*, and special cases for mips n32 and sparc64. I'd assume gdb's new elf_internal_linux_prstatus struct would contain a pointer to and size of regs in target format. Host format would be messy since some 64-bit targets have the odd 32-bit reg hidden away in elf_gregset_t. -- Alan Modra Australia Development Lab, IBM