From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16341 invoked by alias); 11 Jun 2004 21:14:34 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 16324 invoked from network); 11 Jun 2004 21:14:31 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 11 Jun 2004 21:14:31 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i5BLEUi7001231 for ; Fri, 11 Jun 2004 17:14:31 -0400 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 i5BLEU024539; Fri, 11 Jun 2004 17:14:30 -0400 Received: from localhost.localdomain (vpn50-38.rdu.redhat.com [172.16.50.38]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id i5BLEUVN021758; Fri, 11 Jun 2004 17:14:30 -0400 Received: from saguaro (saguaro.lan [192.168.64.2]) by localhost.localdomain (8.12.11/8.12.10) with SMTP id i5BLEOQk004054; Fri, 11 Jun 2004 14:14:24 -0700 Date: Fri, 11 Jun 2004 21:14:00 -0000 From: Kevin Buettner To: "Stephen P. Smith" Cc: gdb Subject: Re: shared library support Message-Id: <20040611141424.2bed79f7@saguaro> In-Reply-To: <40AE69AB.7000004@cox.net> References: <40AD1DA8.3090809@cox.net> <40AE69AB.7000004@cox.net> Organization: Red Hat Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2004-06/txt/msg00136.txt.bz2 Stephen, Sorry it took me so long to get back to you on this... On Fri, 21 May 2004 13:42:19 -0700 "Stephen P. Smith" wrote: > In this case, and since some things have changed, I prefer to do it > the correct way. I may need quite abit of direction since I this > will be my first major effort as long as you don't mind. Kevin, > would you please go into more detail about the solib.c support that > you think is needed. In many of the solib-*.c files, you'll see the following: /* FIXME: Don't do this here. *_gdbarch_init() should set so_ops. */ current_target_so_ops = &svr4_so_ops; As indicated by the FIXME, we need some other mechanism for setting the so_ops vector. I think we'll want to do away with the global ``current_target_so_ops'' and create something equivalent using the gdbarch_data machinery. The per-architecture _gdbarch_init() function will initialize the so_ops vector based on the OS/ABI. This machinery is not dissimilar to the way that the link-map-offset fetchers get set up for the various OS/ABIs that use solib-svr4.c as its backend. In a nutshell, we need to have something analogous to set_solib_svr4_fetch_link_map_offsets() for setting the overall solib backend. --- As I've indicated in the past, you'll want to move your shared library support into a solib-something.c file. Look at (and mimic) one or more of the following: solib-svr4.c, solib-irix.c, solib-aix5.c, and solib-frv.c. solib-aix5.c might be of particular interest. Unlike the the other solib backends listed above, this backend does NOT fetch dynamic linker info from the target's memory. It instead reads out of some /proc files. This means that solib-aix5.c will only work for native targets. This particular property is of zero interest to you, but the fact that it uses a different (non-memory-based) mechanism for accessing the dynamic linker data may be. When I write a new solib backend -- I did one recently for FR-V/uClinux -- I make a copy one of the above mentioned files, say solib-svr4.c, rip the guts out of each of the functions that implement the so_ops vector and then delete any remaining unreferenced functions or data structures. I then choose a representation for ``struct lm_info''. (It's worth comparing how this struct differs between each of the files I mention above.) Finally, I reimplement the various function comprising the so_ops vector and add whatever supporting functions and data structures that I find necessary. > One of the things, besides what you have talked about already that > may need done is what do about communicating with the remote target > on this issue. As far as I can tell, there isn't anything in the > remote protocal for the target to let the host know (or for the host > to ask) about shared libraries. But that is for a future disussion. Most of the current shared library backends read the dynamic linker data out of memory. I happen to like this approach because it means that the shared library implementation stays the same for native and remote targets. That said, there are definitely some operating environments which don't fit this mold and it'd be really nice to have a remote protocol extension for handling it. Please post your protocol related proposals to gdb@sources.redhat.com. > Also would you want me to submit these changes as a series of small > patches, or big ones. We generally like looking at small patches better than large ones. That said, there are instances when large patches are acceptable. One such case is when you want to show the overall direction that you're taking. In such a case, you can post a large patch, but clearly indicate that you intend to break it up into smaller pieces for actual review. Also, new files are usually submitted all at once. So, for example, if you had a new shared library backend called solib-foo.c, you'd submit this file as part of a single patch. Kevin