This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
RE: gcc and -fPIC
- From: "Dave Korn" <dk at artimi dot com>
- To: "'Gerhard Wiesinger'" <gerhard at wiesinger dot com>,<binutils at sources dot redhat dot com>,<gcc-help at gcc dot gnu dot org>
- Date: Fri, 15 Oct 2004 18:53:25 +0100
- Subject: RE: gcc and -fPIC
> -----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 <X::f()+0xc>
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....