From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20742 invoked by alias); 19 Jun 2007 19:19:30 -0000 Received: (qmail 20732 invoked by uid 22791); 19 Jun 2007 19:19:29 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 19 Jun 2007 19:19:26 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 57EB8982FB; Tue, 19 Jun 2007 19:19:24 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id EED28982FA; Tue, 19 Jun 2007 19:19:23 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.67) (envelope-from ) id 1I0jEo-0006t3-S0; Tue, 19 Jun 2007 15:19:38 -0400 Date: Tue, 19 Jun 2007 19:19:00 -0000 From: Daniel Jacobowitz To: Ulrich Weigand Cc: gdb-patches@sourceware.org, Pedro Alves Subject: Re: For example only, updated Windows DLL support and gdbserver DLL support Message-ID: <20070619191938.GA26206@caradoc.them.org> Mail-Followup-To: Ulrich Weigand , gdb-patches@sourceware.org, Pedro Alves References: <20070618150816.GA24037@caradoc.them.org> <200706191905.l5JJ5pcj014266@d12av02.megacenter.de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200706191905.l5JJ5pcj014266@d12av02.megacenter.de.ibm.com> User-Agent: Mutt/1.5.15 (2007-04-09) 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-06/txt/msg00377.txt.bz2 On Tue, Jun 19, 2007 at 09:05:51PM +0200, Ulrich Weigand wrote: > One thing I don't quite like is this: > > > + case TARGET_OBJECT_LIBRARIES: > > + if (core_vec->xfer_shared_libraries != NULL) > > + return core_vec->xfer_shared_libraries (ops, object, annex, readbuf, > > + writebuf, offset, len); > > I had understood the core_fns method of providing a core file target to > be deprecated, and in fact I just recently got rid of it for AIX in favour > of the gdbarch_regset_from_core_section callback ... I'd prefer this to > be a gdbarch callback (which would also support core file cross-debugging). I hadn't even thought about it. Yes, you're right. > It looks like the only way to get this to work within the regular solib > framework would be to actually teach solib.c itself about this form of > archive members. Yes, I think you're right. How about we add an optional member="" attribute to , and make the common solib.c code open it? We'd also have to allow .o files. I'm not sure how much trouble you'll have reporting the correct relocations for an object file. Do you get something based on sections, or do AIX object files have a fixed number of segments? One thing I've thought of doing is having
tags, as an alternative to segment; or they could have id="N" instead of using section name, or whatever else was necessary. So far I haven't needed it, but it would work for e.g. Linux KGDB which also loads .o files. Though that's just an example; actually, for KGDB I'd rather have a bit of Python distributed with GDB or with the kernel that knows how to list additional "libraries" :-) -- Daniel Jacobowitz CodeSourcery