From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11427 invoked by alias); 21 Oct 2011 11:05:27 -0000 Received: (qmail 11416 invoked by uid 22791); 21 Oct 2011 11:05:26 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 21 Oct 2011 11:05:12 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=EU1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1RHCuV-0002iQ-CJ from pedro_alves@mentor.com ; Fri, 21 Oct 2011 04:05:11 -0700 Received: from scottsdale.localnet ([172.16.63.104]) by EU1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Oct 2011 12:05:09 +0100 From: Pedro Alves To: Jan Kratochvil Subject: Re: [patch 3/3] Implement qXfer:libraries for Linux/gdbserver #2 Date: Fri, 21 Oct 2011 13:32:00 -0000 User-Agent: KMail/1.13.6 (Linux/2.6.38-11-generic; KDE/4.7.1; x86_64; ; ) Cc: gdb-patches@sourceware.org, Paul Pluzhnikov References: <20111003215530.GC20272@host1.jankratochvil.net> <201110062009.24796.pedro@codesourcery.com> <20111021094258.GA23101@host1.jankratochvil.net> In-Reply-To: <20111021094258.GA23101@host1.jankratochvil.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110211205.06852.pedro@codesourcery.com> 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-10/txt/msg00591.txt.bz2 On Friday 21 October 2011 10:42:58, Jan Kratochvil wrote: > On Thu, 06 Oct 2011 21:09:24 +0200, Pedro Alves wrote: > > but this reuse of is a mistake. > > already supports the "segment" format and "section" format. > SVR4 attributes are just another format of . > Or do you agree there should rather have been and > and it is kept this way for backward compatibility? No, it's not the same. The support, in either the segment or section variants is completely self-described. solib-target.c knows nothing about the target --- the reported tells GDB which unit of relocation the target uses, either a section or a segment. Everything is abstracted, and gdb is given a simplified view. Your proposal violates that -- gdb still knows upfront that the target is svr4-ish, and you still go through solib-svr4.c. The assumption that there's only one segment is really nasty too. The correct solutions are: - Report the library list with , _and_ make gdb use solib-target.c. What minimal extensions would solib-target.c need so that we could make that work, without hardcoding "svr4" semantics? E.g., is defined to _not_ return an element for the main executable. Would we need an extension (a new element, say?) for that? Or is the qOffsets mechanism sufficient for relocating the main executable? - Still us solib-svr4.c, but then don't abuse , but instead add a new packet and target object to accelerate getting at the link map. TARGET_OBJECT_SVR4_LIBRARIES or TARGET_OBJECT_SVR4_LINKMAP or something along those lines. > > If we're not going to use > > an solib-target.c at all, and the semantics of what goes over the > > wire is not the same as /TARGET_OBJECT_LIBRARIES, then > > let's come up with a completely independent new target object + dtd > > instead. Let's call it for example TARGET_OBJECT_SVR4_LIBRARIES. > > > > We should not prevent the possibility of _both_ using solib-svr4.c and > > solib-target.c at the same time, or the possibility of having a completely > > target-side implementation of svr4 libraries in the future, > > I find this implementation as the fully target-side one. SVR4 needs some > information to match symbol files <-> target memory wrt prelinked files and to > aid libthread_db. If you're still using solib-svr4.c for other things than fetching the link map, then it's not a fully target-side one. If the implementation ends up with svr4_so_ops installed in the inferior instead of solib_target_so_ops, then it's not a fully target-side one. > Maybe DYNAMIC segment offset could be sent the other way (host->target) to > match the prelink displacement. And also struct link_map address for > libthread_db may not be transferred > and TLS variables could be read by special packets instead. We already have "qGetTLSAddr", and that's used over gdbarch_fetch_tls_load_module_address -> svr4_lpXX_fetch_link_map_offsets. Are you thinking of something else? > I do not find any of the cases to have advantage, though. One advantage I was considering would be that making the target manage (and hide from gdb) the shared library event breakpoint itself, we'd cut the roundtrips of hitting and stepping over the breakpoint in half (gdb wouldn't see the step), and we'd make the target always keep that breakpoint inserted too, avoiding extra plant/unplant roundtrips for that breakpoint too. But since with a fully target-managed DSO list, we'd end up reporting dso loads/unloads anyway with TARGET_WAITKIND_LOADED (`T05:...:library' in the RSP), it may not be much of a gain, and, most importantly, we can get the same benefits with other generic changes, such as teaching the server side to step over breakpoints itself, and making gdb be smart to not remove/insert that breakpoint constantly (`set breakpoint always-inserted on' by default or maybe just apply that to some breakpoints). So the benefits indeed aren't clear. But that is not to say we won't find benefits in the future, and we're free to mess up the design. And that's why I'm personally okay with still using solib-svr4.c, _provided_ we come up with a new target object (and packets and dtd) to fetch the DSO list from the link map efficiently. > > using as is (and having gdb be aware that support is present > > from qXfer:read:libraries+ in qSupported). > > That is you suggest to have also new qXfer:read:svr4libraries+? Yes. We need a new packet for a each new target object: TARGET_OBJECT_AUXV -> qXfer:read:auxv TARGET_OBJECT_LIBRARIES -> qXfer:read:libraries TARGET_OBJECT_SIGNAL_INFO -> qXfer:read:siginfo TARGET_OBJECT_FDPIC -> qXfer:read:fdpid TARGET_OBJECT_SVR4_LIBRARIES -> qXfer:read:svr4libraries TARGET_OBJECT_SVR4_LINKMAP -> qXfer:read:svr4linkmap .... > I do not follow how differently / more target-side could be the libraries > implemented on SVR4 systems, I already tried to implement it that way. -- Pedro Alves