Re: MI solib notification

[Daniel Jacobowitz <drow@false.org>]

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