From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19469 invoked by alias); 20 Feb 2003 22:30:42 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 19462 invoked from network); 20 Feb 2003 22:30:41 -0000 Received: from unknown (HELO admin1.cvtt.net) (209.133.53.91) by 172.16.49.205 with SMTP; 20 Feb 2003 22:30:41 -0000 Received: (qmail 21759 invoked by uid 89); 20 Feb 2003 22:24:19 -0000 Message-ID: <20030220222419.21758.qmail@admin1.cvtt.net> From: mrcompiler@mrcompiler.com To: gdb@sources.redhat.com Subject: Multi-Arch symbol read warning message Date: Thu, 20 Feb 2003 22:30:00 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-SW-Source: 2003-02/txt/msg00452.txt.bz2 I am building a multi-arch version of GDB for handling ELF format core files for the ARM and PowerPC processors running on vxWorks. In order to get everything to build I combined the information from config/powerpc/vxworks.mt and config/arm/embed.mt and made the appropriate changes necessary to compile with GDB_MULTI_ARCH=GDB_MULTI_ARCH_PURE. The top level config is: ./configure --target=arm-vxworks --enable-targets=strongarm-coff, powerpc-elf, strongarm-elf I was not able to get it working with --enable-targets=all since bfd couldn't resolve the appropriate architecture, but that's a secondary issue. I had to set the target to arm-vxworks instead of powerpc-vxworks in order to get the appropriate remote stuff to link. Otherwise it was off to hack the configure.in and related files which seemed like an extraordinary amount of unecessary work. Everything seems to work fine except for one, probably cosmetic, issue. When I load a PowerPC symbol-file I get the warning "unknown symbol descriptor `;`" which doesn't appear if I build a "pure" powerpc-vxworks target. Using gdb on gdb it seems like this is related somehow to the native target. I have two questions: 1) does this indicate a significant issue? 2) If not is there a solution other than suppressing the warning in dbxread.c? A prompt response would be appreciated greatly as my boss is breathing down my neck to make this available. I'd have to have my team debugging with a faulty debugger. Thanks, Gene