From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29111 invoked by alias); 20 Apr 2008 04:54:24 -0000 Received: (qmail 29088 invoked by uid 22791); 20 Apr 2008 04:54:23 -0000 X-Spam-Check-By: sourceware.org Received: from igw3.br.ibm.com (HELO igw3.br.ibm.com) (32.104.18.26) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 20 Apr 2008 04:54:02 +0000 Received: from mailhub3.br.ibm.com (unknown [9.18.232.110]) by igw3.br.ibm.com (Postfix) with ESMTP id BE00C3900C9 for ; Sun, 20 Apr 2008 01:40:38 -0300 (BRST) Received: from d24av02.br.ibm.com (d24av02.br.ibm.com [9.18.232.47]) by mailhub3.br.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m3K4s0OZ3997860 for ; Sun, 20 Apr 2008 01:54:00 -0300 Received: from d24av02.br.ibm.com (loopback [127.0.0.1]) by d24av02.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m3K4rw7J020904 for ; Sun, 20 Apr 2008 01:53:59 -0300 Received: from [9.8.1.114] ([9.8.1.114]) by d24av02.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m3K4rwjX020890; Sun, 20 Apr 2008 01:53:58 -0300 Subject: Re: [rfc/rft] ppc gdbserver: autodetect AltiVec and SPE From: Thiago Jung Bauermann To: Daniel Jacobowitz Cc: Ulrich Weigand , gdb-patches@sourceware.org In-Reply-To: <20080419035837.GB22517@caradoc.them.org> References: <200803262021.m2QKLTWs019049@d12av02.megacenter.de.ibm.com> <1208563645.5808.90.camel@localhost.localdomain> <20080419035837.GB22517@caradoc.them.org> Content-Type: text/plain Date: Sun, 20 Apr 2008 14:28:00 -0000 Message-Id: <1208667119.5808.126.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 Content-Transfer-Encoding: 7bit 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: 2008-04/txt/msg00417.txt.bz2 On Fri, 2008-04-18 at 23:58 -0400, Daniel Jacobowitz wrote: > On Fri, Apr 18, 2008 at 09:07:25PM -0300, Thiago Jung Bauermann wrote: > > gdbserver is not compiling anymore on Linux/ppc. I believe this patch is > > the cause: > > > > gcc -Wall -g -O2 -I. -I../../../gdb.hg/gdb/gdbserver -I../../../gdb.hg/gdb/gdbserver/../regformats -I../../../gdb.hg/gdb/gdbserver/../../include -I../../bfd -I../../../gdb.hg/gdb/gdbserver/../../bfd -rdynamic -o gdbserver inferiors.o regcache.o remote-utils.o server.o signals.o target.o utils.o version.o mem-break.o hostio.o xml-builtin.o reg-ppc.o powerpc-32.o reg-ppc64.o powerpc-64.o linux-low.o linux-ppc-low.o hostio-errno.o thread-db.o proc-service.o \ > > -lthread_db > > linux-ppc-low.o: In function `ppc_arch_setup': > > ../../../gdb.hg/gdb/gdbserver/linux-ppc-low.c:255: undefined reference to `init_registers_powerpc_e500' > > collect2: ld returned 1 exit status > > make[4]: *** [gdbserver] Error 1 > > make[4]: Leaving directory `/home/bauermann/tmp/remove-dead-fn/build/gdb/gdbserver' > > Looks like you have to rerun configure. Maybe a missing dependency > somewhere (Makefile on configure.srv?). No, it was a clean build. I got what's happening. The patch removed powerpc-e500.o from powerpc64-*-linux*, because e500 is 32-bit only. The call to init_registers_powerpc_e500 is protected by an #ifndef __powerpc64__, so it shouldn't be a problem. But in practice it is, because when using plain "../src/configure && make" in a ppc64 machine with a 32-bit default gcc, the target is autodetected to be powerpc64-unknown-linux-gnu. Thus, that call to init_registers_powerpc_e500 will be compiled in (it's a 32 bit compilation), but powerpc-e500.o won't be included (it's a powerpc64 target). Is such way of compiling 32-bit GDB in a ppc64 machine with 32-bit default gcc not supported? Must one always use --target option to configure in such case? -- []'s Thiago Jung Bauermann Software Engineer IBM Linux Technology Center