From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12635 invoked by alias); 29 Jun 2010 18:21:44 -0000 Received: (qmail 12618 invoked by uid 22791); 29 Jun 2010 18:21:43 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 29 Jun 2010 18:21:39 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 76E712BAB8A; Tue, 29 Jun 2010 14:21:37 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id QP3nyE19TJm2; Tue, 29 Jun 2010 14:21:37 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 190832BAB88; Tue, 29 Jun 2010 14:21:37 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 45A37F5895; Tue, 29 Jun 2010 11:21:32 -0700 (PDT) Date: Tue, 29 Jun 2010 18:21:00 -0000 From: Joel Brobecker To: Jan Kratochvil Cc: gdb-patches@sourceware.org Subject: Re: ping: [patch 2/6] PIE: Attach binary even after ld.so re-prelinked underneath Message-ID: <20100629182132.GS2595@adacore.com> References: <20100329161657.GA2940@host0.dyn.jankratochvil.net> <20100609150815.GB7183@host0.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100609150815.GB7183@host0.dyn.jankratochvil.net> User-Agent: Mutt/1.5.20 (2009-06-14) 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: 2010-06/txt/msg00680.txt.bz2 > gdb/ > 2010-03-29 Jan Kratochvil > > * auxv.c (ld_so_xfer_auxv): Do not error on failed read of data_address. > > gdb/testsuite/ > 2010-03-29 Jan Kratochvil > > * gdb.base/break-interp.exp (test_attach): Keep $interp changed. Move > its restore after the <$relink_args != ""> loop. new comment. The code changes themselves look reasonable, but as discussed on IRC, I think the comments could have more info. If you want, we can commit the code, and update the comments as a followup patch. I think we can also converge on the comments within a day or two, so your choice. > + /* While it is an error I am not aware how to solve attaching to PIE under > + valgrind --db-attach=yes different way when ld.so on-disk file has prelink > + change in the meantime. Currently GDB will drop back to procfs_xfer_auxv > + (so that at least non-valgrind PIE attachments with prelink change of > + ld.so work). To make it working even with valgrind is PR 11440 requiring > + a valgrind extension. */ In this case, I think we need to split the explanation that provides the situation when the memory read error could happen; what we are doing in this case (returning -1 to fallback on another xfer method) and its consequences in terms of correctness; and the problem that is left to solve. Something like this, perhaps? /* The location of the _dl_auxv symbol may no longer be correct if ld.so was prelinked after the program was started, which can cause the memory read at its address to fail. When that happens, return -1 to fallback on another mechanism for retrieving the AUXV. While this allows things to work in most cases, this still does not work in the case where we are attaching the debugger to a PIE running under valgrind and --db-attach=yes (again, when the on-disk ld.so file was changed due to prelink after the process was started). [WHY???] However, we have not found a solution to that problem yet, and we think that we might need a valgrind extension to make it work. This is PR 11440. */ > foreach relink {YES NO} { > - if {[prelink$relink $relink_args [file tail $exec]] > - && [copy $interp_saved $interp]} { > + # It would be more correct to also [copy $interp_saved $interp] > + # here to really test just different prelink of $exec. > + # But we would need a separate test for different prelink of ld.so > + # where a bug occured. It is now all merged into this single test. > + if [prelink$relink $relink_args [file tail $exec]] { > # /proc/PID/exe cannot be loaded as it is "EXECNAME (deleted)". > test_attach_gdb $exec $pid $displacement "attach-relink$relink" As discussed on IRC, let's expand the comment to provide the explanation that your provided there. Basically: * what we used to do (the copy) and why (restore ld.so to prevent an ld.so prelink) * why we are no longer doing it (making sure that we test GDB with ld.so being prelinked too) -- Joel