From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17868 invoked by alias); 8 Jul 2007 17:21:42 -0000 Received: (qmail 17860 invoked by uid 22791); 8 Jul 2007 17:21:41 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 08 Jul 2007 17:21:38 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 332D89829E; Sun, 8 Jul 2007 17:21:37 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 090649829C; Sun, 8 Jul 2007 17:21:36 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.67) (envelope-from ) id 1I7aRy-0005dq-TV; Sun, 08 Jul 2007 13:21:34 -0400 Date: Sun, 08 Jul 2007 17:21:00 -0000 From: Daniel Jacobowitz To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: Building solib-target.c when CORE_ADDR != ULONGEST. Message-ID: <20070708172134.GA21380@caradoc.them.org> Mail-Followup-To: Pedro Alves , gdb-patches@sourceware.org References: <46903BF1.6020901@portugalmail.pt> <20070708012711.GA12934@caradoc.them.org> <4690F562.9060009@portugalmail.pt> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4690F562.9060009@portugalmail.pt> User-Agent: Mutt/1.5.15 (2007-04-09) 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: 2007-07/txt/msg00140.txt.bz2 On Sun, Jul 08, 2007 at 03:32:02PM +0100, Pedro Alves wrote: > About the VEC in question. I noticed that the xml parsing > xmalloc's the memory for the ULONGEST, but it is safe to > pass a pointer in a local var, right? Yes, that's right. The patch is OK. > I got confused because in vec.h: > > "Because of the different behavior of structure objects, scalar > objects and of pointers, there are three flavors, one for each of > these variants. Both the structure object and pointer variants > pass pointers to objects around -- in the former case the pointers > are stored into the vector and in the latter case the pointers are > dereferenced and the objects copied into the vector. The scalar > object variant is suitable for int-like objects, and the vector > elements are returned by value. " > > Something in there confuses me. The former/latter type of > descriptions adds an indirection that I always find > distracting. Far as I can tell, Nathan got his formers and his latters crossed, and that's why it doesn't make sense. It would have made more sense for me to use DEF_VEC_I for these than the DEF_VEC_O I actually used, but to be honest I didn't realize it was there. The use of DEF_VEC_O makes this rather more confusing than necessary. > The 'by value' statement isn't clear to me either: > "object variant is suitable for int-like objects, and the vector > elements are returned by value. " > > T *VEC_T_index(VEC(T) *v, unsigned ix); // Object > > ? What does 'by value' mean then? The previous word is "scalar". Scalar object -> integer, not structure object. So the last bit of your correction is wrong. > 2007-07-08 Pedro Alves > > * solib-target.c (library_list_start_segment): Cast address to CORE_ADDR. OK. -- Daniel Jacobowitz CodeSourcery