From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12767 invoked by alias); 2 Oct 2009 18:38:51 -0000 Received: (qmail 12753 invoked by uid 22791); 2 Oct 2009 18:38:50 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS 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; Fri, 02 Oct 2009 18:38:45 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n92Ic3QX019539; Fri, 2 Oct 2009 14:38:03 -0400 Received: from host0.dyn.jankratochvil.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id n92Ic0cA009192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Oct 2009 14:38:02 -0400 Received: from host0.dyn.jankratochvil.net (localhost [127.0.0.1]) by host0.dyn.jankratochvil.net (8.14.3/8.14.3) with ESMTP id n92Ibx9J024253; Fri, 2 Oct 2009 20:37:59 +0200 Received: (from jkratoch@localhost) by host0.dyn.jankratochvil.net (8.14.3/8.14.3/Submit) id n92IbvvI024250; Fri, 2 Oct 2009 20:37:57 +0200 Date: Fri, 02 Oct 2009 18:38:00 -0000 From: Jan Kratochvil To: Mark Kettenis Cc: brobecker@adacore.com, tromey@redhat.com, ralf.corsepius@rtems.org, gdb@sourceware.org Subject: Re: GDB 6.8.92 available for testing Message-ID: <20091002183756.GA23588@host0.dyn.jankratochvil.net> References: <20090930204828.GB31446@adacore.com> <4AC41F44.1040502@rtems.org> <20091001170744.GC6532@adacore.com> <4AC4E4F6.5080500@rtems.org> <4AC630C8.5090508@rtems.org> <200910021804.n92I47I7008266@brahms.sibelius.xs4all.nl> <20091002181447.GS6532@adacore.com> <200910021823.n92INVuX003644@brahms.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200910021823.n92INVuX003644@brahms.sibelius.xs4all.nl> User-Agent: Mutt/1.5.20 (2009-08-17) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-10/txt/msg00053.txt.bz2 On Fri, 02 Oct 2009 20:23:31 +0200, Mark Kettenis wrote: > I think that would be a bad idea since size_t will be a 64-bit type on > 64-bit hosts. This will increase memory usage on 6-bit hosts. We do need 64-bit target TYPE_LENGTH support. There exist >2GB debuginfos: http://cvs.fedora.redhat.com/viewvc/rpms/gdb/devel/gdb-6.3-bz231832-obstack-2gb.patch?view=co and I guess some HPC (High Performance Computing) is already exceeding it for runtime data object size. With dynamic data type sizes (archer-jankratochvil-vla) such current dynamic size is stored in TYPE_LENGTH. Just it should not be size_t but target_size_t. Yes, it should be CORE_ADDR. Regards, Jan