From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3058 invoked by alias); 21 Jul 2011 18:36:25 -0000 Received: (qmail 2865 invoked by uid 22791); 21 Jul 2011 18:36:24 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 21 Jul 2011 18:36:08 +0000 Received: (qmail 22789 invoked from network); 21 Jul 2011 18:36:07 -0000 Received: from unknown (HELO scottsdale.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 21 Jul 2011 18:36:07 -0000 From: Pedro Alves To: Sergio Durigan Junior Subject: Re: [PATCH] On-demand loading of shlib's debuginfo Date: Thu, 21 Jul 2011 19:21:00 -0000 User-Agent: KMail/1.13.6 (Linux/2.6.38-8-generic; KDE/4.6.2; x86_64; ; ) Cc: gdb-patches@sourceware.org, Jan Kratochvil References: <201107211158.45196.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107211936.04731.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-07/txt/msg00593.txt.bz2 On Thursday 21 July 2011 19:14:50, Sergio Durigan Junior wrote: > Pedro Alves writes: > > > On Wednesday 20 July 2011 21:53:14, Jan Kratochvil wrote: > >> On Tue, 19 Jul 2011 00:23:49 +0200, Sergio Durigan Junior wrote: > >> > With that in mind, we decided to tackle this problem progressively, and the > >> > first part of the solution is ready for submission. > >> > >> That is currently it still touches the solib files on disk for the purpose of > >> solib_map_sections so that will be a different patch, looking forward. > > > > I had skimmed the patch only, and reserved commenting until I had > > a chance of reading the patch carefuly and figuring it out > > myself, but since you raise this... > > > > Is that the reason then that svr4_match_pc_solist goes through > > the link map to map a PC to a so_list, instead of having a > > generic implementation that matches the PC to the so_list's > > loaded (bfd) sections (that is, just call solib_contains_address_p) ? > > If so, it'd make more sense IMO to remove that from this patch, > > and add it only along with a change that lazies mapping in the bfd > > and its sections as well. I'm not sure how safe that will be. > > Thanks for the comments, both of you. After some chat with Jan, I have > decided that I will work on the second part of this task, i.e., take > care of solib_map_sections inside update_solib_list, and will only > submit a new patch when it's done. Oh, well:-) I thought the separation was good, as: - target sections are used for "set trust-readonly-sections on" and similar fallbacks to reading memory from the exec, which requires separate dso lazy load points (disassembly? printing some address?). - its not clear to me the pc -> dso mapping from the link map is faster than from the bfd in all scenarios. E.g., on remote targets, it may be faster to get at the bfd info on the host, than to remote read memory from the target. - I was curious on how much lazing debug info alone was helping, vs lazing the bfd reads. -- Pedro Alves