From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12047 invoked by alias); 8 Aug 2011 18:56:33 -0000 Received: (qmail 11930 invoked by uid 22791); 8 Aug 2011 18:56:32 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.44.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 08 Aug 2011 18:56:13 +0000 Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id p78IuCa1013941 for ; Mon, 8 Aug 2011 11:56:12 -0700 Received: from gyb11 (gyb11.prod.google.com [10.243.49.75]) by wpaz1.hot.corp.google.com with ESMTP id p78ItZPe022824 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 8 Aug 2011 11:56:11 -0700 Received: by gyb11 with SMTP id 11so1151198gyb.38 for ; Mon, 08 Aug 2011 11:56:11 -0700 (PDT) Received: by 10.150.47.35 with SMTP id u35mr6323612ybu.88.1312829771315; Mon, 08 Aug 2011 11:56:11 -0700 (PDT) Received: by 10.150.47.35 with SMTP id u35mr6323607ybu.88.1312829771167; Mon, 08 Aug 2011 11:56:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.48.15 with HTTP; Mon, 8 Aug 2011 11:55:40 -0700 (PDT) In-Reply-To: <20110808183613.GA31998@host1.jankratochvil.net> References: <20110808183613.GA31998@host1.jankratochvil.net> From: Paul Pluzhnikov Date: Mon, 08 Aug 2011 18:56:00 -0000 Message-ID: Subject: Re: [patch] Implement qXfer:libraries for Linux/gdbserver [Was: Re: [RFC] Make target_read_string faster over high-latency links.] To: Jan Kratochvil Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-IsSubscribed: yes 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: 2011-08/txt/msg00151.txt.bz2 On Mon, Aug 8, 2011 at 11:36 AM, Jan Kratochvil 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