From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-49474-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 10261 invoked by alias); 18 Jun 2007 20:10:55 -0000
Received: (qmail 10250 invoked by uid 22791); 18 Jun 2007 20:10:55 -0000
X-Spam-Check-By: sourceware.org
Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 18 Jun 2007 20:10:52 +0000
Received: (qmail 13127 invoked from network); 18 Jun 2007 20:10:50 -0000
Received: from unknown (HELO localhost) (jimb@127.0.0.2)   by mail.codesourcery.com with ESMTPA; 18 Jun 2007 20:10:50 -0000
To: gdb-patches@sourceware.org
Cc: Ulrich Weigand <uweigand@de.ibm.com>, 	  Pedro Alves <pedro_alves@portugalmail.pt>
Subject: Re: [rfc] Shared libraries over the remote protocol, take two
References: <20070618150211.GA23415@caradoc.them.org>
From: Jim Blandy <jimb@codesourcery.com>
Date: Mon, 18 Jun 2007 20:10:00 -0000
In-Reply-To: <20070618150211.GA23415@caradoc.them.org> (Daniel Jacobowitz's message of "Mon, 18 Jun 2007 11:02:11 -0400")
Message-ID: <m3hcp5qb05.fsf@codesourcery.com>
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-IsSubscribed: yes
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
X-SW-Source: 2007-06/txt/msg00347.txt.bz2


Daniel Jacobowitz <drow@false.org> writes:
> +/* Private data for each loaded library.  */
> +struct lm_info
> +{
> +  /* The library's name.  The name is normally kept in the struct
> +     so_list; it is only here during XML parsing.  */
> +  char *name;
> +
> +  /* The number of entries in SEGMENT_BASES.  */
> +  int num_bases;
> +
> +  /* The base addresses for each independently relocatable segment of
> +     this shared library.  */
> +  CORE_ADDR *segment_bases;
> +
> +  /* The cached offsets for each section of this shared library,
> +     determined from SEGMENT_BASES.  */
> +  struct section_offsets *offsets;
> +};

I'm not too familiar with VECs, but is there some reason not to use a
VEC for segment_bases, as well?