From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14084 invoked by alias); 6 Mar 2009 00:58:04 -0000 Received: (qmail 14075 invoked by uid 22791); 6 Mar 2009 00:58:02 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 06 Mar 2009 00:57:57 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 0180D2BABEB; Thu, 5 Mar 2009 19:57:59 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id AoTlo50fRXZi; Thu, 5 Mar 2009 19:57:58 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id C42392BABE8; Thu, 5 Mar 2009 19:57:58 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 7944CE7ACD; Thu, 5 Mar 2009 16:57:53 -0800 (PST) Date: Fri, 06 Mar 2009 00:58:00 -0000 From: Joel Brobecker To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [commit/Tru64] bring back the Tru64 port to life... Message-ID: <20090306005753.GG3744@adacore.com> References: <20090305235503.GK3793@adacore.com> <200903060028.40871.alves.ped@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200903060028.40871.alves.ped@gmail.com> User-Agent: Mutt/1.4.2.2i 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 Mail-Followup-To: gdb-patches@sourceware.org X-SW-Source: 2009-03/txt/msg00073.txt.bz2 > Can nsecs be 0 here? Good question. It seems pretty highly unlikely, but I'm not sure whether this is possible or not. I couldn't find a whole lot of documentation about the lmi_nregion field in ldr_module_info_t. But from the code in solib-osf.c, it looks like this field is actually the number of sections. I don't see how a shared library could have zero section and yet still be loaded. If the naming in solib-osf.c got me confused, and the secs array actually refers to memory regions, you'd think that there would be at least one region for the code. > Since it is checked at least here: Yeah, that's strange. I can add an extra check, but... > struct lm_info > { > int isloader; /* whether the module is /sbin/loader */ > int nsecs; /* length of .secs */ > struct lm_sec secs[1]; /* variable-length array of sections, sorted > by name */ > }; The previous code was a glorified version of malloc (offsetof (struct lm_info, secs) + nsecs * sizeof (struct lm_sec)) The new expression I used should be strictly equivalent: malloc (sizeof (struct lm_info) + (nsecs - 1) * sizeof (struct lm_sec)); In both cases, if nsecs is zero, we end up allocating less memory than sizeof (struct lm_info). Intuitively, it seems OK, since we shouldn't really access the secs array if nsecs is null. One easy way out is to change the allocation to allocate one extra entry in the secs array. It's slightly wasteful, but it's just a few bytes times the number of shared libraries. What do you think? -- Joel