This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: MI solib notification
- From: Vladimir Prus <vladimir at codesourcery dot com>
- To: Daniel Jacobowitz <drow at false dot org>, Marc Khouzam <marc dot khouzam at ericsson dot com>
- Cc: gdb-patches at sources dot redhat dot com, Nick Roberts <nickrob at snap dot net dot nz>
- Date: Thu, 12 Feb 2009 12:12:52 +0300
- Subject: Re: MI solib notification
- References: <200901310010.46738.vladimir@codesourcery.com> <20090201180423.GC4597@caradoc.them.org>
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