From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5903 invoked by alias); 5 Jan 2012 15:25:15 -0000 Received: (qmail 5877 invoked by uid 22791); 5 Jan 2012 15:25:12 -0000 X-SWARE-Spam-Status: No, hits=-6.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 05 Jan 2012 15:24:59 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q05FOvqP014210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Jan 2012 10:24:57 -0500 Received: from host2.jankratochvil.net (ovpn-116-35.ams2.redhat.com [10.36.116.35]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q05FOpZF018844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 5 Jan 2012 10:24:54 -0500 Date: Thu, 05 Jan 2012 15:25:00 -0000 From: Jan Kratochvil To: Ulrich Weigand Cc: gdb-patches@sourceware.org Subject: Re: [patch 2/2] Fix linking on non-x86* after libgdb.a removal Message-ID: <20120105152451.GA4548@host2.jankratochvil.net> References: <20120104204235.GA20047@host2.jankratochvil.net> <201201051446.q05EkJVV016755@d06av02.portsmouth.uk.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201201051446.q05EkJVV016755@d06av02.portsmouth.uk.ibm.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-01/txt/msg00192.txt.bz2 On Thu, 05 Jan 2012 15:46:19 +0100, Ulrich Weigand wrote: > Jan Kratochvil wrote: > > For targets using new set_gdbarch_regset_from_core_section it would not be > > a problem, just put corelow.o into the right entry of gdb/configure.tgt. > > Huh, at least for s390 this would certainly be the correct solution; the > target actually is fully switched to modern gdbarch core handling ... I agree and I forgot to write that at least some - at least s390 - targets properly work with core files on cross-gdb. But still some other targets do not. I find such fix(es) outside of the scope of this proposed patch. As I found for example on sparc*-tdep.c files it is not so obvious which are and which are not already converted. > This needs to be done anyway to properly handle cross-debugging targeting > s390 core files. Unless you already have done so, I can prepare a patch. Sure such (separate) patch would be great. > Maybe a better way would be to just unconditionally add corelow.o to > COMMON_OBS and be done with it? What would be the harm in having the > core target always present, even in configurations where no core file > formats will be recognized? Currently GDB writes: GDB can't read core files on this machine. I guess it will load the core file without recognizing its registers? I do not have available any core file from the legacy *-tdep.c archs. That can be considered a regression. > Or, if we want to keep the existing behaviour exactly, we could just > filter out all objects from TARGET_OBS that are already present in > NATDEPFILES (or vice versa). This would at least avoid the ad-hoc > handling of one specific file ... I think one cannot do such filtering in a cross-platform way from Makefile. But I agree it can be done from configure.ac. I can rework it that way. There needs to be some exception for ALL_TARGET_OBS which are not known to configure.ac, I considered this as a blocker but I see it is not. Thanks, Jan