From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3286 invoked by alias); 28 Jan 2011 01:05:37 -0000 Received: (qmail 3276 invoked by uid 22791); 28 Jan 2011 01:05:36 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (74.125.121.67) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 28 Jan 2011 01:05:31 +0000 Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id p0S15SWW021637 for ; Thu, 27 Jan 2011 17:05:28 -0800 Received: from iwn39 (iwn39.prod.google.com [10.241.68.103]) by kpbe19.cbf.corp.google.com with ESMTP id p0S13XsX028323 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 27 Jan 2011 17:05:27 -0800 Received: by iwn39 with SMTP id 39so2713813iwn.41 for ; Thu, 27 Jan 2011 17:05:26 -0800 (PST) Received: by 10.42.219.73 with SMTP id ht9mr3039843icb.390.1296176726777; Thu, 27 Jan 2011 17:05:26 -0800 (PST) Received: from coign.google.com ([216.239.45.130]) by mx.google.com with ESMTPS id u5sm12866524ics.18.2011.01.27.17.05.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 27 Jan 2011 17:05:26 -0800 (PST) From: Ian Lance Taylor To: Gregory Shtrasberg Cc: gcc-help@gcc.gnu.org Subject: Re: R_386_RELATIVE question References: <30775689.post@talk.nabble.com> <30782193.post@talk.nabble.com> <30782769.post@talk.nabble.com> Date: Fri, 28 Jan 2011 07:24:00 -0000 In-Reply-To: <30782769.post@talk.nabble.com> (Gregory Shtrasberg's message of "Thu, 27 Jan 2011 15:52:11 -0800 (PST)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-System-Of-Record: true X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2011-01/txt/msg00430.txt.bz2 Gregory Shtrasberg writes: > It's shared library because it's where I've encountered such a case for the > first time. I guess it could have been any executable as well. > My point is that everywhere else when I tell the linker to preserve its > relocations (-Wl,-q) if there is an address stored as a data, there is a > relocation on it, which points to the address, so I can tell that it's > actually an address and not some random data. > It becomes important when I'm altering the binary. For example, I want to > switch positions of two functions or insert nops in random places. That's > what I mean by "reassembling". Of course then I need to fix all the > addresses. > And here is address that doesn't have such a relocation on it, though from > what I know there should have been one and I'm trying to figure out why is > that. > So, basically there are two questions: > 1. Am I right about that there should have been a relocation? > 2. Why it isn't there? I see what you are getting at. The -q option copies the existing relocations into the executable. The R_386_RELATIVE reloc here is a brand new relocation created by the linker. One could imagine that the linker would emit a different relocation when using -q, but it doesn't. One could also imagine that it would leave the dynamic reloc alone but would emit a new regular reloc, but it doesn't do that either. I have no opinion as to whether this is a bug. There is no documented behaviour for -q with shared libraries or for -q with dynamic relocations. I'll note that you do have all the information you need. You can look at the section contents to see what the R_386_RELATIVE refers to. You should be able to calculate how that address moves thanks to your manipulations, and you should be able to adjust the section contents accordingly. But I agree that it would be more convenient and possibly more reliable to have the symbol name. Ian