From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25280 invoked by alias); 14 Dec 2006 17:34:12 -0000 Received: (qmail 25233 invoked by uid 22791); 14 Dec 2006 17:34:11 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate5.de.ibm.com (HELO mtagate5.de.ibm.com) (195.212.29.154) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 14 Dec 2006 17:33:59 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.13.8/8.13.8) with ESMTP id kBEHXt5q212772; Thu, 14 Dec 2006 17:33:55 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kBEHXtgh2986122; Thu, 14 Dec 2006 18:33:55 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kBEHXtga031204; Thu, 14 Dec 2006 18:33:55 +0100 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id kBEHXt2f031201; Thu, 14 Dec 2006 18:33:55 +0100 Message-Id: <200612141733.kBEHXt2f031201@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Thu, 14 Dec 2006 18:33:55 +0100 Subject: Re: spu-gdb vs. stabs To: amodra@bigpond.net.au (Alan Modra) Date: Thu, 14 Dec 2006 17:34:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org, binutils@sourceware.org In-Reply-To: <20061214071839.GD6013@bubble.grove.modra.org> from "Alan Modra" at Dec 14, 2006 05:48:39 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: 2006-12/txt/msg00193.txt.bz2 Alan Modra wrote: > There are a number of ways to fix this. One is to modify dbxread.c > to accept a zero return from bfd_get_size. Another is to make the > default iovec stat function return INT_MAX in st_size to effectively > circumvent the dbxread.c checks. I chose to extend bfd_openr_iovec > to accept a user "stat" function so that the actual size can be > provided, but then cowardly decided to just return a size of INT_MAX > in the spu implementation for stat. See the comment. That sounds great, thanks! > If the kernel > /proc file used to find the address of a spu embedded binary also > returned the size then we could easily provide a better stat > function. That's not so easy, the information gets lost during embedding already. It would require ABI changes throughout the process ... If we really need a proper size at some point, I think parsing the ELF headers should suffice for that. > gdb/ > * spu-linux-nat.c (spu_bfd_iovec_stat): New function. > (spu_bfd_open): Adjust bfd_openr_iovec call. This is OK, except ... > +#ifdef INT_MAX > + sb->st_size = INT_MAX; > +#else > + sb->st_size = ((unsigned) -1) >> 1; > +#endif ... GDB's defs.h already has a fallback definition for INT_MAX, so you can just use the macro unconditionally here. Thanks, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com