From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18277 invoked by alias); 3 Oct 2011 19:51:17 -0000 Received: (qmail 18267 invoked by uid 22791); 3 Oct 2011 19:51:16 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,RCVD_NUMERIC_HELO,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 03 Oct 2011 19:51:00 +0000 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RAoXQ-0007Th-Mm for gdb-patches@sources.redhat.com; Mon, 03 Oct 2011 21:50:58 +0200 Received: from 209.226.137.108 ([209.226.137.108]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 03 Oct 2011 21:50:56 +0200 Received: from aristovski by 209.226.137.108 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 03 Oct 2011 21:50:56 +0200 To: gdb-patches@sources.redhat.com From: Aleksandar Ristovski Subject: Re: patch: solib_break from _r_debug.r_brk Date: Mon, 03 Oct 2011 19:51:00 -0000 Message-ID: References: <4E847A11.6080800@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0 In-Reply-To: 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/msg00043.txt.bz2 I will have to withdraw this patch. The reason is that on gnu ld, this would not work since _r_debug is initialized differently, causing it to always read zero. In theory, when attaching to a running process, this patch could still yield sensible results, but then I'm not sure it is generic enough to warrant inclusion in the official sources. For completeness, here are two other things I have found further testing the patch on gnu/linux: sym->section for _r_debug will be SEC_ALLOC so cmp_name_and_sec_flags would always return 0. Second issue is that once the symbol is correctly found, fetched address would have to be checked for relocation since it could be already relocated in case of attaching to a running process. Due to above, even though the patch works fine for me, I see no point pursuing it further for fsf gdb. Thanks, Aleksandar