From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24921 invoked by alias); 15 Oct 2004 17:54:00 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 24902 invoked from network); 15 Oct 2004 17:53:59 -0000 Received: from unknown (HELO NUTMEG.CAM.ARTIMI.COM) (217.40.111.177) by sourceware.org with SMTP; 15 Oct 2004 17:53:59 -0000 Received: from mace ([192.168.1.25]) by NUTMEG.CAM.ARTIMI.COM with Microsoft SMTPSVC(6.0.3790.0); Fri, 15 Oct 2004 18:53:25 +0100 From: "Dave Korn" To: "'Gerhard Wiesinger'" , , Subject: RE: gcc and -fPIC Date: Fri, 15 Oct 2004 17:54:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In-Reply-To: Message-ID: X-OriginalArrivalTime: 15 Oct 2004 17:53:25.0689 (UTC) FILETIME=[DEB23A90:01C4B2DF] X-SW-Source: 2004-10/txt/msg00113.txt.bz2 > -----Original Message----- > From: binutils-owner On Behalf Of Gerhard Wiesinger > Sent: 15 October 2004 18:08 > I've the following problem with a *.so file and a dynamically linked > C++ new operator. To follow the bug I tried objdump which > produced some > output, but not the one I assumed. So I made some tests with > the program > discussed below and the new operator. I analysed some > disassembly code and > it looks like that objdump can not handle -fPIC compiled code > correctly. You probably a false alarm here. > Why is there a call at location 80485b3? How is anyone meant to know when you haven't shown us the source code for X::f? The odds are that without -fPIC, something got inlined, which could not be inlined with -fPIC (perhaps owing to increased register pressure from the use of a pic base register). > 80485b3: e8 00 00 00 00 call 80485b8 However, what I suspect is really bothering you is that you can't understand why it would be calling to the very next instruction. Fortunately, that isn't what's happening. You're looking at the dump from a relocatable object file. That call instruction hasn't been relocated yet. So the correct destination hasn't been filled in yet. You should add the "-r" flag to see the reloc relating to the call instruction, then you'll know what symbol it's really calling. cheers, DaveK -- Can't think of a witty .sigline today....