From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12445 invoked by alias); 15 May 2008 12:19:46 -0000 Received: (qmail 12434 invoked by uid 22791); 15 May 2008 12:19:44 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 15 May 2008 12:19:25 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 94272983D6; Thu, 15 May 2008 12:19:23 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 76A939830E; Thu, 15 May 2008 12:19:23 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1JwcQc-0002Dd-NR; Thu, 15 May 2008 08:19:22 -0400 Date: Thu, 15 May 2008 17:16:00 -0000 From: Daniel Jacobowitz To: Ulrich Weigand Cc: gdb-patches@sourceware.org Subject: Re: [rfc] Fix problem with (maybe) non-relocated .opd section on powerpc64-linux Message-ID: <20080515121922.GD7597@caradoc.them.org> Mail-Followup-To: Ulrich Weigand , gdb-patches@sourceware.org References: <200805142302.m4EN2nHg030353@d12av02.megacenter.de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200805142302.m4EN2nHg030353@d12av02.megacenter.de.ibm.com> User-Agent: Mutt/1.5.17 (2008-05-11) 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: 2008-05/txt/msg00465.txt.bz2 On Thu, May 15, 2008 at 01:02:49AM +0200, Ulrich Weigand wrote: > However, this is not the case if the library is loaded via dlopen. In this > case, the _dl_debug_state breakpoint is hit *before* relocations are applied. > (I guess this might be considered a bug in glibc. But we have to live with > existing glibc's in the field anyway ...) Not that I disagree with your conclusions, but this is a sorry state of affairs. There's a status field in struct r_debug; what is it when this happens? RT_ADD or RT_CONSISTENT? RT_ADD is supposed to happen before the object is added to the list, and RT_CONSISTENT after it has been relocated. We can end up loading inconsistent shared libraries, if we're between those two points and someone does "info shared", but this happens rarely and it's not the case here. I feel like we've discussed this problem before, in one of the various revisions of the same patch we were discussing yesterday, but I can't find it. > So to solve this I'm now completely ignoring contents of .opd in target > memory, and instead always retrieve the contents from the BFD. Those > will certainly be non-relocated, so applying the relocation offset by > hand will always result in the correct target address. > > Is this a reasonable thing to do? We went round the choice of where to read memory from several times on the previous patch, but I don't know the details. -- Daniel Jacobowitz CodeSourcery