From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19315 invoked by alias); 12 Feb 2009 09:12:58 -0000 Received: (qmail 19302 invoked by uid 22791); 12 Feb 2009 09:12:58 -0000 X-SWARE-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_13,KAM_STOCKTIP,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 12 Feb 2009 09:12:53 +0000 Received: (qmail 15941 invoked from network); 12 Feb 2009 09:12:51 -0000 Received: from unknown (HELO wind.local) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 12 Feb 2009 09:12:51 -0000 From: Vladimir Prus To: Daniel Jacobowitz , Marc Khouzam Subject: Re: MI solib notification Date: Thu, 12 Feb 2009 09:12:00 -0000 User-Agent: KMail/1.9.10 Cc: gdb-patches@sources.redhat.com, Nick Roberts References: <200901310010.46738.vladimir@codesourcery.com> <20090201180423.GC4597@caradoc.them.org> In-Reply-To: <20090201180423.GC4597@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902121212.53025.vladimir@codesourcery.com> 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/msg00279.txt.bz2 On Sunday 01 February 2009 21:04:23 Daniel Jacobowitz wrote: > 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. Eclipse does use this, in particular consider this bit of code: public boolean hasSharedLibChanged(SharedLibrary lib, MIShared miLib) { return !miLib.getName().equals(lib.getFileName()) || !MIFormat.getBigInteger(miLib.getFrom()).equals(lib.getStartAddress()) || !MIFormat.getBigInteger(miLib.getTo()).equals(lib.getEndAddress()) || miLib.isRead() != lib.areSymbolsLoaded(); } Now, we know this is never going to happen in practice, when using GDB, and this is GDB-specific code, so maybe we can drop addresses from the GDB output and then DSF folks will make sure they don't use start/end addresses? > > 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. Well, not necessary, due to this code in clear_solib: 903 if (exec_bfd != NULL 904 && bfd_get_flavour (exec_bfd) != bfd_target_aout_flavour) 905 disable_breakpoints_in_shlibs (); So, I think we'll only get additional chatter on a.out targets -- do we care? - Volodya