public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* gcc and -fPIC
@ 2004-10-15 17:08 Gerhard Wiesinger
  2004-10-15 17:54 ` Dave Korn
  2004-10-15 19:55 ` Andreas Schwab
  0 siblings, 2 replies; 15+ messages in thread
From: Gerhard Wiesinger @ 2004-10-15 17:08 UTC (permalink / raw)
  To: binutils, gcc-help

Hello!

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.

============================================================
But there goes something wrong with objdump and the -fPIC option of gcc:
080485ac <X::f()>:
  80485ac:       55                      push   %ebp
  80485ad:       89 e5                   mov    %esp,%ebp
  80485af:       53                      push   %ebx
  80485b0:       83 ec 04                sub    $0x4,%esp
  80485b3:       e8 00 00 00 00          call   80485b8 <X::f()+0xc>
  80485b8:       5b                      pop    %ebx
  80485b9:       81 c3 5c 12 00 00       add    $0x125c,%ebx
  80485bf:       8b 45 08                mov    0x8(%ebp),%eax
  80485c2:       ff 00                   incl   (%eax)
  80485c4:       8b 45 08                mov    0x8(%ebp),%eax
  80485c7:       81 38 e7 03 00 00       cmpl   $0x3e7,(%eax)
  80485cd:       76 02                   jbe    80485d1 <X::f()+0x25>
  80485cf:       eb 10                   jmp    80485e1 <X::f()+0x35>
  80485d1:       83 ec 0c                sub    $0xc,%esp
  80485d4:       ff 75 08                pushl  0x8(%ebp)
  80485d7:       e8 0a 00 00 00          call   80485e6 <X::g()>
  80485dc:       83 c4 10                add    $0x10,%esp
  80485df:       eb e3                   jmp    80485c4 <X::f()+0x18>
  80485e1:       8b 5d fc                mov    0xfffffffc(%ebp),%ebx
  80485e4:       c9                      leave
  80485e5:       c3                      ret

Why is there a call at location 80485b3?
============================================================
Without -fPIC it looks ok:
0804859e <X::f()>:
  804859e:       55                      push   %ebp
  804859f:       89 e5                   mov    %esp,%ebp
  80485a1:       83 ec 08                sub    $0x8,%esp
  80485a4:       8b 45 08                mov    0x8(%ebp),%eax
  80485a7:       ff 00                   incl   (%eax)
  80485a9:       8b 45 08                mov    0x8(%ebp),%eax
  80485ac:       81 38 e7 03 00 00       cmpl   $0x3e7,(%eax)
  80485b2:       76 02                   jbe    80485b6 <X::f()+0x18>
  80485b4:       eb 10                   jmp    80485c6 <X::f()+0x28>
  80485b6:       83 ec 0c                sub    $0xc,%esp
  80485b9:       ff 75 08                pushl  0x8(%ebp)
  80485bc:       e8 07 00 00 00          call   80485c8 <X::g()>
  80485c1:       83 c4 10                add    $0x10,%esp
  80485c4:       eb e3                   jmp    80485a9 <X::f()+0xb>
  80485c6:       c9                      leave
  80485c7:       c3                      ret
============================================================

gcc version: 3.3.3
objdump version: 2.15.90.0.3

So is the code gcc produces (in)correct, or objdump can't read any 
Position Independent Code?

Any ideas?

Thank you for the answer.

Ciao,
Gerhard

/*
         OK:
                 g++ -g testnew.cpp -o testnew
                 objdump --dynamic-syms --private -S -C testnew | less -I
         NOK
                 g++ -fPIC -g testnew.cpp -o testnew
                 objdump --dynamic-syms --private -S -C testnew | less -I
*/

class X
{
public:
         X() {}

         void g()
         {
                 x++;
         }

         void f()
         {
                 x++;
                 while (x < 1000)
                 {
                         g();
                 }
         }

protected:
         unsigned long x;
};

int main(int argc, char* argv[])
{
         X* x = new X;
         X* xarray = new X[10];

         x->f();

         delete x;
         delete [] xarray;
}

^ permalink raw reply	[flat|nested] 15+ messages in thread
* Re: gcc and -fPIC
@ 2004-10-15 18:26 bserdar
  2004-10-15 18:46 ` Dave Korn
  2004-10-15 18:51 ` Gerhard Wiesinger
  0 siblings, 2 replies; 15+ messages in thread
From: bserdar @ 2004-10-15 18:26 UTC (permalink / raw)
  To: Gerhard Wiesinger; +Cc: binutils, gcc-help


>  80485b3:       e8 00 00 00 00          call   80485b8 <X::f()+0xc>
>  80485b8:       5b                      pop    %ebx
>  80485b9:       81 c3 5c 12 00 00       add    $0x125c,%ebx

With pop ebx, it pops the eip at that instruction to ebx. I'm guessing it'll use ebx as a base pointer to data (or code?) from this point on. You can verify this guess by accessing some global variables from within X::f() and see whether it uses ebx-relative access.

^ permalink raw reply	[flat|nested] 15+ messages in thread
* Re: gcc and -fPIC
@ 2004-10-15 18:58 bserdar
  0 siblings, 0 replies; 15+ messages in thread
From: bserdar @ 2004-10-15 18:58 UTC (permalink / raw)
  To: Gerhard Wiesinger; +Cc: gcc-help

> 
> OK, but why is the function call at 80485b3 to the next address at 
> 80485b8?
> 
> Is the call relocated at runtime (if yes, to what address or 
> function) or 
> can this not be handled by objdump?

It's a relative call. It is not relocated. 

> 
> Thank you for the answer.
> 
> Ciao,
> Gerhard
> 

^ permalink raw reply	[flat|nested] 15+ messages in thread
end of thread, other threads:[~2004-10-18  5:17 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-10-15 17:08 gcc and -fPIC Gerhard Wiesinger
2004-10-15 17:54 ` Dave Korn
2004-10-15 19:55 ` Andreas Schwab
2004-10-16  6:06   ` Gerhard Wiesinger
2004-10-16 12:09     ` Andreas Schwab
2004-10-16 15:17       ` Daniel Jacobowitz
2004-10-17 18:57         ` Gerhard Wiesinger
2004-10-17 19:31           ` Daniel Jacobowitz
2004-10-18  5:17             ` Gerhard Wiesinger
2004-10-15 18:26 bserdar
2004-10-15 18:46 ` Dave Korn
2004-10-15 18:51 ` Gerhard Wiesinger
2004-10-15 19:11   ` Jeffrey A Law
2004-10-15 19:16     ` Gerhard Wiesinger
2004-10-15 18:58 bserdar

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).