Re: MI solib notification

[Vladimir Prus <vladimir@codesourcery.com>]

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