From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24651 invoked by alias); 7 Aug 2007 23:20:01 -0000 Received: (qmail 24486 invoked by uid 22791); 7 Aug 2007 23:20:00 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 07 Aug 2007 23:19:57 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l77NJt9s012584 for ; Tue, 7 Aug 2007 19:19:55 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l77NJtuO004381 for ; Tue, 7 Aug 2007 19:19:55 -0400 Received: from ironwood.lan (vpn-14-203.rdu.redhat.com [10.11.14.203]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l77NJsNi003220 for ; Tue, 7 Aug 2007 19:19:54 -0400 Date: Tue, 07 Aug 2007 23:20:00 -0000 From: Kevin Buettner To: gdb-patches@sources.redhat.com Subject: Re: [RFA] fix build failure in solib-som.c Message-ID: <20070807161954.748a5eb5@ironwood.lan> In-Reply-To: <20070807224348.GA3738@adacore.com> References: <20070807204529.GA3681@adacore.com> <20070807144733.26f94534@ironwood.lan> <20070807224348.GA3738@adacore.com> X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.10.4; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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-08/txt/msg00140.txt.bz2 On Tue, 7 Aug 2007 15:43:48 -0700 Joel Brobecker wrote: > > > I haven't tested this change, but wouldn't the attached patch make sense? > > > I don't think we need to keep track of which section is the text section > > > at this place, since this is done differently somewhere else (in the > > > current_sos method). So I just removed the associated piece of code. > > > > > > 2007-08-07 Joel Brobecker > > > > > > * solib-som.c (som_relocate_section_addresses): Stop saving > > > the $CODE$ section in the so_list structure. > > > > > > This files compiles fine again after this change is applied. > > > > > > Would that be OK to apply? > > > > I think it would be better to revise the code to set so->addr_low and > > so->addr_high to sec->addr and sec->endaddr respectively. You'll also > > have to move this block of code to the end of the function. > > Isn't that already done in som_current_sos, though? It is, but those addresses won't be relocated. In order to be consistent with the other ports, I think these values should be relocated. Note that solib.c's solib_map_sections() sets `addr_low' and `addr_high' for .text after the relocation has been done. Clearly this won't work for SOM since the .text section is named differently. However, given that `addr_low' and `addr_high' are set after the relocation has been performed (for other ports with a .text), I think it makes sense to arrange the SOM-specific code as suggested in my earlier reply. I'm beginning to think too that the assignments to addr_low and addr_high ought to be removed from som_current_sos(). That said, it's not critical that `addr_low' and `addr_high' be relocated since they're only used for display purposes in "info sharedlibrary". If it makes more sense for this port to display unrelocated values, them I'm happy with your original patch. I'll leave it to you to decide the best course of action. Kevin