From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24945 invoked by alias); 27 Jan 2011 23:15:33 -0000 Received: (qmail 24937 invoked by uid 22791); 27 Jan 2011 23:15:32 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.44.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 27 Jan 2011 23:15:27 +0000 Received: from kpbe20.cbf.corp.google.com (kpbe20.cbf.corp.google.com [172.25.105.84]) by smtp-out.google.com with ESMTP id p0RNFP1r003928 for ; Thu, 27 Jan 2011 15:15:25 -0800 Received: from gyb11 (gyb11.prod.google.com [10.243.49.75]) by kpbe20.cbf.corp.google.com with ESMTP id p0RNEJqV017170 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 27 Jan 2011 15:15:24 -0800 Received: by gyb11 with SMTP id 11so968176gyb.5 for ; Thu, 27 Jan 2011 15:15:24 -0800 (PST) Received: by 10.151.26.18 with SMTP id d18mr3530468ybj.48.1296170123760; Thu, 27 Jan 2011 15:15:23 -0800 (PST) Received: from coign.google.com ([216.239.45.130]) by mx.google.com with ESMTPS id g58sm2198147yhd.5.2011.01.27.15.15.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 27 Jan 2011 15:15:23 -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> Date: Thu, 27 Jan 2011 23:26:00 -0000 In-Reply-To: <30782193.post@talk.nabble.com> (Gregory Shtrasberg's message of "Thu, 27 Jan 2011 14:22:14 -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/msg00425.txt.bz2 Gregory Shtrasberg writes: > What I ment to say is if I want to reassemble the code in some way, the > address of __dso_handle will change. Naturally, every other place that has > address in the data section has a linker relocation on it, like R_386_32, > which also tells me that the value is an address and needs to be altered. So > that I can change the value according to new code order, e.g. 08 1c 00 00 > will become the new address of __dso_handle. > But here the only relocation here unlike other places is R_386_RELATIVE, > which, as you said does different thing. > So, this looks to me as some sort of bug in gcc. Or am I missing something? You are looking at a shared library, created using gcc -shared. I can tell because only shared libraries have R_386_RELATIVE relocations. I'm not sure what you mean by "reassemble", but it is certainly true that you can not add new code to an existing shared library, any more than you can add new code to an existing fully linked executable. A shared library essentially is an executable, just one that happens to be position independent. Let me know if that does not make sense. Ian