From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23233 invoked by alias); 15 May 2008 16:15:21 -0000 Received: (qmail 23121 invoked by uid 22791); 15 May 2008 16:15:16 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate4.de.ibm.com (HELO mtagate4.de.ibm.com) (195.212.29.153) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 15 May 2008 16:14:54 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.13.8/8.13.8) with ESMTP id m4FGEpsx271658 for ; Thu, 15 May 2008 16:14:51 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m4FGEpj13305634 for ; Thu, 15 May 2008 18:14:51 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m4FGEoTu004044 for ; Thu, 15 May 2008 18:14:50 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id m4FGEo8M004041; Thu, 15 May 2008 18:14:50 +0200 Message-Id: <200805151614.m4FGEo8M004041@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Thu, 15 May 2008 18:14:50 +0200 Subject: Re: [rfc] Fix problem with (maybe) non-relocated .opd section on powerpc64-linux To: drow@false.org (Daniel Jacobowitz) Date: Thu, 15 May 2008 17:40:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <20080515121922.GD7597@caradoc.them.org> from "Daniel Jacobowitz" at May 15, 2008 08:19:22 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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/msg00467.txt.bz2 Daniel Jacobowitz wrote: > 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. Well, it seems that this field is set to RT_CONSISTENT *before* the objects are relocated (from elf/dl-open.c): /* Notify the debugger all new objects are now ready to go. */ struct r_debug *r = _dl_debug_initialize (0, args->nsid); r->r_state = RT_CONSISTENT; _dl_debug_state (); /* Only do lazy relocation if `LD_BIND_NOW' is not set. */ lazy = (mode & RTLD_BINDING_MASK) == RTLD_LAZY && GLRO(dl_lazy); /* Relocate the objects loaded. We do this in reverse order so that copy relocs of earlier objects overwrite the data written by later objects. */ struct link_map *l = new; while (l->l_next) l = l->l_next; while (1) { if (! l->l_real->l_relocated) { #ifdef SHARED if (__builtin_expect (GLRO(dl_profile) != NULL, 0)) { /* If this here is the shared object which we want to profile make sure the profile is started. We can find out whether this is necessary or not by observing the `_dl_profile_map' variable. If was NULL but is not NULL afterwars we must start the profiling. */ struct link_map *old_profile_map = GL(dl_profile_map); _dl_relocate_object (l, l->l_scope, 1, 1); if (old_profile_map == NULL && GL(dl_profile_map) != NULL) { /* We must prepare the profiling. */ _dl_start_profile (); /* Prevent unloading the object. */ GL(dl_profile_map)->l_flags_1 |= DF_1_NODELETE; } } else #endif _dl_relocate_object (l, l->l_scope, lazy, 0); } if (l == new) break; l = l->l_prev; } > > 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. OK, thanks. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com