From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10660 invoked by alias); 7 Dec 2004 17:28:55 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 10619 invoked from network); 7 Dec 2004 17:28:50 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 7 Dec 2004 17:28:50 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id iB7HSje9011727 for ; Tue, 7 Dec 2004 12:28:45 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id iB7HSir16683; Tue, 7 Dec 2004 12:28:44 -0500 Received: from localhost.localdomain (vpn50-35.rdu.redhat.com [172.16.50.35]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id iB7HSiGE022328; Tue, 7 Dec 2004 12:28:44 -0500 Received: from ironwood.lan (ironwood.lan [192.168.64.8]) by localhost.localdomain (8.12.11/8.12.10) with SMTP id iB7HScbS017495; Tue, 7 Dec 2004 10:28:38 -0700 Date: Tue, 07 Dec 2004 17:31:00 -0000 From: Kevin Buettner To: Randolph Chung Cc: gdb-patches@sources.redhat.com Subject: Re: [rfc] first cut of solib-som.[ch] Message-ID: <20041207102838.190db2d3.kevinb@redhat.com> In-Reply-To: <20041207052424.GU6359@tausq.org> References: <20041207052424.GU6359@tausq.org> Organization: Red Hat Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2004-12/txt/msg00204.txt.bz2 On Mon, 6 Dec 2004 21:24:24 -0800 Randolph Chung wrote: > Here's a first cut at SOM solib support using the new solib > infrastructure. I hope this is somewhat cleaner than the original > somsolib.c. The in_dynsym_resolve_code method is still really ugly; i > hope to revisit that later. Can someone please review this and let me > know if i'm on the right track? Yes, you're definitely on the right track. Thanks for doing this work! > I've done some light testing with this > using hppa2.0w-hp-hpux11.11. In some ways it works better than the > existing code (e.g. info sharedlib will segfault the current gdb in > cvs, but using this version works) > > If this is ok, i'll check it in without linking it to anything. Will > work on converting pa64solib next, and once that is ready we can enable > that for hpux targets. Sure, sounds good to me. > One interesting bit for hpux is that for hppa64-hpux, to support both > 32-bit and 64-bit debugging at the same time, we will need multiarched > solib support as well. My plan is to call either som_solib_select () > [below] or pa64_solib_select () in the osabi sniffer to set the correct > current_target_so_ops. Is that how it is supposed to work? Yes, this seems reasonable. (At least for the short term; I think Mark is working on something for the long term...) Just one comment about the way you structured things... > +enum dld_list_offsets { > + DLD_LIST_OFFSET_NAME = 0, > + DLD_LIST_OFFSET_INFO = 4, > + DLD_LIST_OFFSET_TEXT_ADDR = 8, > + DLD_LIST_OFFSET_TEXT_LINK_ADDR = 12, > + DLD_LIST_OFFSET_TEXT_END = 16, > + DLD_LIST_OFFSET_DATA_START = 20, > + DLD_LIST_OFFSET_BSS_START = 24, > + DLD_LIST_OFFSET_DATA_END = 28, > + DLD_LIST_OFFSET_GOT_VALUE = 32, > + DLD_LIST_OFFSET_NEXT = 36, > + DLD_LIST_OFFSET_TSD_START_ADDR_PTR = 40, > + DLD_LIST_ENTRY_SIZE = 44 > +}; I have no real quarrel with using offsets as you do above; in fact, I think such offsets have worked out quite well for solib-svr4. However, given that you have only one set of offsets to worry about, it might be easier in some respects to use an actual struct where each member is a char array. (Daniel J showed me this trick...) So, for the above, you might instead do: struct dld_list { unsigned char name[4]; unsigned char info[4]; unsigned char text_addr[4]; ... }; And then, for example, in som_current_sos(), instead of doing: char dbuf[DLD_LIST_ENTRY_SIZE]; ... addr = extract_unsigned_integer (&dbuf[DLD_LIST_OFFSET_NAME], 4); You, could instead do: struct dld_list dbuf; ... addr = extract_unsigned_integer (&dbuf.name, sizeof(dbuf.name)); Kevin