Re: [patch] Implement qXfer:libraries for Linux/gdbserver [Was: Re: [RFC] Make target_read_string faster over high-latency links.]

[Paul Pluzhnikov <ppluzhnikov@google.com>]

On Mon, Aug 8, 2011 at 11:36 AM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:

> GDB could reuse solib-target.c

That is in fact where I started.

The trouble is that solib-target.c's notion of what info is in solib->lm_info
is radically different from solib-svr4.c's notion, each having a private
and distinct 'struct lm_info'. Un-tangling that seemed troublesome.

> It would make libexpat mandatory even for the linux-nat.c usage so libexpat
> could be bundler into the sourceware tree.

I think it's highly desirable to keep the current solib-srv4 code working
(e.g. in case you have a gdbserver that answers with empty list; either
because it is old, or because it's for a platform that hasn't been updated).

Given above, you can always fall back to it when libexpat is not detected.

> I do not say it would say LoC but it would be more clean, currently there
> would be two isolated producer + consumer pairs of the same protocol.

Yes, the two isolated consumers are a bit bothersome.

The producers would have to stay separate anyway, as the details of getting
the list differ greatly.

Thanks,
-- 
Paul Pluzhnikov