From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15928 invoked by alias); 19 Jan 2016 03:14:16 -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 15905 invoked by uid 89); 19 Jan 2016 03:14:15 -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=non-native, nonnative, 2011-10, 201110 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-pa0-f43.google.com Received: from mail-pa0-f43.google.com (HELO mail-pa0-f43.google.com) (209.85.220.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 19 Jan 2016 03:14:13 +0000 Received: by mail-pa0-f43.google.com with SMTP id uo6so429509625pac.1; Mon, 18 Jan 2016 19:14:13 -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=Mp7KrnJjLLiekd8Dc/Ldqg6ywNCBFA9/QYIeicr9P7E=; b=GhgsUw/9Hn/fEl7yiqhOzrWBRBqv2CxexqJYPTpPY+PbGyqLKXRCmFMUOp9lxN2Fds KkmlOP/15NtqmL6k+n7tl/efwgw1F5OdGLrViATCL6KySkqjxUXAmDsBCYak06UEol+g foTBNpZMS6CH52y3m29/ez7wYC9garUhmlXmGXfGtSqWdCRGhglSSzaOYGrIjSNM87kN dL7xOoh+k3tWrDM394qxWbnHj+76MGtTJ2Ff4aY45lrIYKVVVlie2DkD7lvf4LibCMGR 9wTGbhz/RwCw1aG4R1sm4/xvr7I3orp6A1wOzcKAQooxP5ECZ7RODp6ZdQ/pHMcWlZZt ggLQ== X-Gm-Message-State: AG10YOSkjY3DSQB4RY19hNddmABHnHKSiHM19ByvuqMbQUGfkFRAbni3e+jKcCqJ7Hlqyg== X-Received: by 10.66.232.132 with SMTP id to4mr20053150pac.95.1453173252230; Mon, 18 Jan 2016 19:14:12 -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 u21sm37119990pfi.15.2016.01.18.19.14.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Jan 2016 19:14:11 -0800 (PST) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 542A5EA017A; Tue, 19 Jan 2016 13:44:07 +1030 (ACDT) Date: Tue, 19 Jan 2016 03:14:00 -0000 From: Alan Modra To: John Baldwin , Ulrich Weigand Cc: binutils@sourceware.org, gdb@sourceware.org Subject: Re: Are ppc*_elf_write_core_note Os-specific? Message-ID: <20160119031407.GD17028@bubble.grove.modra.org> References: <1736699.V7zq9VJIrx@ralph.baldwin.cx> <20160119001819.GB17028@bubble.grove.modra.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160119001819.GB17028@bubble.grove.modra.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2016-01/txt/msg00029.txt.bz2 On Tue, Jan 19, 2016 at 10:48:19AM +1030, Alan Modra wrote: > PowerPC64 glibc even now doesn't defing prstatus32_t. :-( It seems > only sparc and s390 do so. So PowerPC would need a > hosts/powerpc-linux.h to define them for Linux, with some configury > changes, like hosts/x86-64linux.h does for x86-64 Linux. I'll see > about making those changes. > > Note that elf_backend_write_core_note is defined for x86-64, arm and > aarch64 too. The ARM and AARCH64 functions look to be completely > redundant, and I suspect all of them could disappear if we modify the > generic code to handle prstatusx32_t for x86-64. Actually, there is a reason for the ARM and AARCH64 functions. See https://sourceware.org/ml/binutils/2011-10/msg00202.html Note the followup emails too.. So it seems that with the current infrastructure we can either support core file generation on remote (linux) targets, or core file generation on more native targets (freebsd). Alternatively, we'd need to use separate bfd target vectors for linux and freebsd, which can and will cause multiple target matches. Do we really want non-native core file generation? -- Alan Modra Australia Development Lab, IBM