From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20186 invoked by alias); 5 Jan 2012 14:46:41 -0000 Received: (qmail 20175 invoked by uid 22791); 5 Jan 2012 14:46:40 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from e06smtp14.uk.ibm.com (HELO e06smtp14.uk.ibm.com) (195.75.94.110) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 05 Jan 2012 14:46:25 +0000 Received: from /spool/local by e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 5 Jan 2012 14:46:23 -0000 Received: from d06nrmr1307.portsmouth.uk.ibm.com ([9.149.38.129]) by e06smtp14.uk.ibm.com ([192.168.101.144]) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 5 Jan 2012 14:46:21 -0000 Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1307.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q05EkLXB1917132 for ; Thu, 5 Jan 2012 14:46:21 GMT Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q05EkK5V016790 for ; Thu, 5 Jan 2012 07:46:21 -0700 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id q05EkJVV016755; Thu, 5 Jan 2012 07:46:19 -0700 Message-Id: <201201051446.q05EkJVV016755@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Thu, 05 Jan 2012 15:46:19 +0100 Subject: Re: [patch 2/2] Fix linking on non-x86* after libgdb.a removal To: jan.kratochvil@redhat.com (Jan Kratochvil) Date: Thu, 05 Jan 2012 14:46:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <20120104204235.GA20047@host2.jankratochvil.net> from "Jan Kratochvil" at Jan 04, 2012 09:42:35 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit x-cbid: 12010514-1948-0000-0000-0000008FEF94 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/msg00182.txt.bz2 Jan Kratochvil wrote: > this is the second part for solving corelow after the s390x regression: > [patch 2/2] Do not build libgdb.a by default > http://sourceware.org/ml/gdb-patches/2011-12/msg00716.html > -> > corelow.o:(.bss+0x0): multiple definition of `core_gdbarch' > corelow.o:(.bss+0x0): first defined here > corelow.o: In function `deprecated_add_core_fns': > corelow.c:(.text+0x0): multiple definition of `deprecated_add_core_fns' > corelow.o:corelow.c:(.text+0x0): first defined here > > > 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 ... 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. > But for legacy targets still using deprecated_add_core_fns (like > sparc-solaris2.6 etc.) the addition to gdb/configure.tgt would enable > corelow.o even for cross-targeted GDBs where there is unfortunately still no > core files support. > > Created the original configuration, just avoiding a duplicate corelow.o entry. > A better idea is welcome. 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? 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 ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com