From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17473 invoked by alias); 1 Feb 2009 18:04:30 -0000 Received: (qmail 17465 invoked by uid 22791); 1 Feb 2009 18:04:30 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 01 Feb 2009 18:04:26 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 30A90107F8; Sun, 1 Feb 2009 18:04:24 +0000 (GMT) Received: from caradoc.them.org (209.195.188.212.nauticom.net [209.195.188.212]) by nan.false.org (Postfix) with ESMTP id EFBEC107F6; Sun, 1 Feb 2009 18:04:23 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1LTggB-0001Mt-Gr; Sun, 01 Feb 2009 13:04:23 -0500 Date: Sun, 01 Feb 2009 18:04:00 -0000 From: Daniel Jacobowitz To: Vladimir Prus Cc: gdb-patches@sources.redhat.com, Nick Roberts Subject: Re: MI solib notification Message-ID: <20090201180423.GC4597@caradoc.them.org> Mail-Followup-To: Vladimir Prus , gdb-patches@sources.redhat.com, Nick Roberts References: <200901310010.46738.vladimir@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200901310010.46738.vladimir@codesourcery.com> User-Agent: Mutt/1.5.17 (2008-05-11) 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: 2009-02/txt/msg00002.txt.bz2 On Sat, Jan 31, 2009 at 12:10:46AM +0300, Vladimir Prus wrote: > +static void mi_solib_loaded (struct so_list *solib) > +{ > + struct mi_interp *mi = top_level_interpreter_data (); > + target_terminal_ours (); > + fprintf_unfiltered (mi->event_channel, > + "library-loaded,id=\"%s\",target-name=\"%s\",host-name=\"%s\",low-address=\"0x%s\",high-address=\"0x%s\",symbols-loaded=\"%d\"", > + solib->so_original_name, solib->so_original_name, > + solib->so_name, > + paddr (solib->addr_low), paddr (solib->addr_high), > + solib->symbols_loaded); > + gdb_flush (mi->event_channel); > +} Do existing clients use addr_low / addr_high from "info shared"? If so, do you know what they use it for? These fields make sense for SVR4 models, like Linux and BSD shared libraries, where shared libraries get a single chunk of address space. But they don't make sense for some DLL systems which load the text and data separately, or for kernel modules where each section can get a different load offset. We should either report the boundaries of the first contiguous piece, which will not cover the whole library, or else the highest and lowest address, which may cover bits of some other library. > diff --git a/gdb/solib.c b/gdb/solib.c > index cce4f7f..5a28292 100644 > --- a/gdb/solib.c > +++ b/gdb/solib.c > @@ -908,6 +908,7 @@ clear_solib (void) > { > struct so_list *so = so_list_head; > so_list_head = so->next; > + observer_notify_solib_unloaded (so); > if (so->abfd) > remove_target_sections (so->abfd); > free_so (so); What sort of effect does this have on the existing hooks? There are two users of this observer; the bsd-uthread.c one looks like it will be fine, but this might make breakpoint.c:disable_breakpoints_in_unloaded_shlib very chatty when you rerun the program. -- Daniel Jacobowitz CodeSourcery