gcc and -fPIC

gcc and -fPIC

[Gerhard Wiesinger]

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;
}

RE: gcc and -fPIC

[Dave Korn]

> -----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....

Re: gcc and -fPIC

[Andreas Schwab]

Gerhard Wiesinger <gerhard@wiesinger.com> writes:

> Why is there a call at location 80485b3?

This is used to load the program counter since the x86 does not have a
pc-relative addressing mode except in calls.  That's the only way to get
the address of the GOT in position independ code.

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

Neither.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: gcc and -fPIC

[Gerhard Wiesinger]

On Fri, 15 Oct 2004, Andreas Schwab wrote:

> Gerhard Wiesinger <gerhard@wiesinger.com> writes:
>
>> Why is there a call at location 80485b3?
>
> This is used to load the program counter since the x86 does not have a
> pc-relative addressing mode except in calls.  That's the only way to get
> the address of the GOT in position independ code.
>
>> So is the code gcc produces (in)correct, or objdump can't read any
>> Position Independent Code?
>
> Neither.
>

BTW: Is it possible to see the dynamic symbols in the disassembly? I don't 
see the call to operator delete[](void*) at location 8048592.
=======================================================================
g++ -fPIC -g testnew.cpp -o testnew
objdump -r -R --dynamic-syms --private-headers -S -C testnew | less -I
=======================================================================
DYNAMIC SYMBOL TABLE:
080483d0      DF *UND*  0000002a  GLIBCPP_3.2 operator delete(void*)
080483e0      DF *UND*  000004d1  CXXABI_1.2  __gxx_personality_v0
080483f0      DF *UND*  000000f3  GLIBC_2.0   __libc_start_main
080486c0 g    DO .rodata        00000004  Base        _IO_stdin_used
08048400      DF *UND*  00000039  GLIBCPP_3.2 operator new[](unsigned int)
08048410      DF *UND*  00000026  GLIBCPP_3.2 operator delete[](void*)
00000000  w   D  *UND*  00000000              _Jv_RegisterClasses
08048420      DF *UND*  000000a3  GLIBCPP_3.2 operator new(unsigned int)
00000000  w   D  *UND*  00000000              __gmon_start__

         delete x;
  8048578:       83 ec 0c                sub    $0xc,%esp
  804857b:       ff 75 f4                pushl  0xfffffff4(%ebp)
  804857e:       e8 4d fe ff ff          call   80483d0 <_init+0x28>
  8048583:       83 c4 10                add    $0x10,%esp
         delete [] xarray;
  8048586:       83 7d f0 00             cmpl   $0x0,0xfffffff0(%ebp)
  804858a:       74 0e                   je     804859a <main+0xba>
  804858c:       83 ec 0c                sub    $0xc,%esp
  804858f:       ff 75 f0                pushl  0xfffffff0(%ebp)
  8048592:       e8 79 fe ff ff          call   8048410 <_init+0x68>
  8048597:       83 c4 10                add    $0x10,%esp
}
  804859a:       b8 00 00 00 00          mov    $0x0,%eax
  804859f:       8d 65 f8                lea    0xfffffff8(%ebp),%esp
  80485a2:       5b                      pop    %ebx
  80485a3:       5e                      pop    %esi
  80485a4:       c9                      leave
  80485a5:       c3                      ret
=======================================================================

When I just disassemble the object file this works well (but not in the 
linked version above):
=======================================================================
g++ -fPIC -g -c testnew.cpp -o testnew.o
objdump -r --private-headers -S -C testnew.o | less -I
=======================================================================
        delete [] xarray;
   a6:   83 7d f0 00             cmpl   $0x0,0xfffffff0(%ebp)
   aa:   74 0e                   je     ba <main+0xba>
   ac:   83 ec 0c                sub    $0xc,%esp
   af:   ff 75 f0                pushl  0xfffffff0(%ebp)
   b2:   e8 fc ff ff ff          call   b3 <main+0xb3>
                         b3: R_386_PLT32 operator delete[](void*)
   b7:   83 c4 10                add    $0x10,%esp
}
=======================================================================

Any ideas to get the symbols also in the linked version?

Thank you.

Ciao,
Gerhard

Re: gcc and -fPIC

[Andreas Schwab]

Gerhard Wiesinger <lists@wiesinger.com> writes:

> BTW: Is it possible to see the dynamic symbols in the disassembly? I don't
> see the call to operator delete[](void*) at location 8048592.

Difficult, because the PLT entries have no symbols attached to them.
There is no information about which PLT entry belongs to which function.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: gcc and -fPIC

[Daniel Jacobowitz]

On Sat, Oct 16, 2004 at 02:09:24PM +0200, Andreas Schwab wrote:
> Gerhard Wiesinger <lists@wiesinger.com> writes:
> 
> > BTW: Is it possible to see the dynamic symbols in the disassembly? I don't
> > see the call to operator delete[](void*) at location 8048592.
> 
> Difficult, because the PLT entries have no symbols attached to them.
> There is no information about which PLT entry belongs to which function.

There's some code in HEAD to do this, written by Jakub.

-- 
Daniel Jacobowitz

Re: gcc and -fPIC

[Gerhard Wiesinger]

On Sat, 16 Oct 2004, Daniel Jacobowitz wrote:

> On Sat, Oct 16, 2004 at 02:09:24PM +0200, Andreas Schwab wrote:
>> Gerhard Wiesinger <lists@wiesinger.com> writes:
>>
>>> BTW: Is it possible to see the dynamic symbols in the disassembly? I don't
>>> see the call to operator delete[](void*) at location 8048592.
>>
>> Difficult, because the PLT entries have no symbols attached to them.
>> There is no information about which PLT entry belongs to which function.
>
> There's some code in HEAD to do this, written by Jakub.
>

Ok, I tried the HEAD version:
DYNAMIC SYMBOL TABLE:
080483d0      DF *UND*  0000002a  GLIBCPP_3.2 operator delete(void*)
080483e0      DF *UND*  000004d1  CXXABI_1.2  __gxx_personality_v0
080483f0      DF *UND*  000000f3  GLIBC_2.0   __libc_start_main
080486c0 g    DO .rodata        00000004  Base        _IO_stdin_used
08048400      DF *UND*  00000039  GLIBCPP_3.2 operator new[](unsigned int)
08048410      DF *UND*  00000026  GLIBCPP_3.2 operator delete[](void*)
00000000  w   D  *UND*  00000000              _Jv_RegisterClasses
08048420      DF *UND*  000000a3  GLIBCPP_3.2 operator new(unsigned int)
00000000  w   D  *UND*  00000000              __gmon_start__

08048410 <_ZdaPv@plt>:
  8048410:       ff 25 3c 98 04 08       jmp    *0x804983c
  8048416:       68 20 00 00 00          push   $0x20
  804841b:       e9 a0 ff ff ff          jmp    80483c0 <_init+0x18>


         delete x;
  8048578:       83 ec 0c                sub    $0xc,%esp
  804857b:       ff 75 f4                pushl  0xfffffff4(%ebp)
  804857e:       e8 4d fe ff ff          call   80483d0 <_ZdlPv@plt>
  8048583:       83 c4 10                add    $0x10,%esp
         delete [] xarray;
  8048586:       83 7d f0 00             cmpl   $0x0,0xfffffff0(%ebp)
  804858a:       74 0e                   je     804859a <main+0xba>
  804858c:       83 ec 0c                sub    $0xc,%esp
  804858f:       ff 75 f0                pushl  0xfffffff0(%ebp)
  8048592:       e8 79 fe ff ff          call   8048410 <_ZdaPv@plt>
  8048597:       83 c4 10                add    $0x10,%esp
}


I got some symbol output, but not the expected one.

But it shouldn't be to difficult to implement because the DYNAMIC SYMBOL 
table above has already the correct symbol.

Ciao,
Gerhard

Re: gcc and -fPIC

[Daniel Jacobowitz]

On Sun, Oct 17, 2004 at 08:57:15PM +0200, Gerhard Wiesinger wrote:
>         delete x;
>  8048578:       83 ec 0c                sub    $0xc,%esp
>  804857b:       ff 75 f4                pushl  0xfffffff4(%ebp)
>  804857e:       e8 4d fe ff ff          call   80483d0 <_ZdlPv@plt>
>  8048583:       83 c4 10                add    $0x10,%esp
>         delete [] xarray;
>  8048586:       83 7d f0 00             cmpl   $0x0,0xfffffff0(%ebp)
>  804858a:       74 0e                   je     804859a <main+0xba>
>  804858c:       83 ec 0c                sub    $0xc,%esp
>  804858f:       ff 75 f0                pushl  0xfffffff0(%ebp)
>  8048592:       e8 79 fe ff ff          call   8048410 <_ZdaPv@plt>
>  8048597:       83 c4 10                add    $0x10,%esp
> }
> 
> 
> I got some symbol output, but not the expected one.
> 
> But it shouldn't be to difficult to implement because the DYNAMIC SYMBOL 
> table above has already the correct symbol.

That's the output I would expect.  If you would rather see the longer
form, pipe the output to c++filt.

-- 
Daniel Jacobowitz

Re: gcc and -fPIC

[Gerhard Wiesinger]

On Sun, 17 Oct 2004, Daniel Jacobowitz wrote:

> On Sun, Oct 17, 2004 at 08:57:15PM +0200, Gerhard Wiesinger wrote:
>>         delete x;
>>  8048578:       83 ec 0c                sub    $0xc,%esp
>>  804857b:       ff 75 f4                pushl  0xfffffff4(%ebp)
>>  804857e:       e8 4d fe ff ff          call   80483d0 <_ZdlPv@plt>
>>  8048583:       83 c4 10                add    $0x10,%esp
>>         delete [] xarray;
>>  8048586:       83 7d f0 00             cmpl   $0x0,0xfffffff0(%ebp)
>>  804858a:       74 0e                   je     804859a <main+0xba>
>>  804858c:       83 ec 0c                sub    $0xc,%esp
>>  804858f:       ff 75 f0                pushl  0xfffffff0(%ebp)
>>  8048592:       e8 79 fe ff ff          call   8048410 <_ZdaPv@plt>
>>  8048597:       83 c4 10                add    $0x10,%esp
>> }
>>
>>
>> I got some symbol output, but not the expected one.
>>
>> But it shouldn't be to difficult to implement because the DYNAMIC SYMBOL
>> table above has already the correct symbol.
>
> That's the output I would expect.  If you would rather see the longer
> form, pipe the output to c++filt.
>

OK, piping through c++filt works well. As I specified the -C switch 
(demangle C++) I would expect that this is demangled too.

But it looks pretty well now :-)

A diff looks like (wthout and with c++filt):
-080483c0 <_ZdlPv@plt-0x10>:
+080483c0 <operator delete(void*)@plt-0x10>:
   80483c0:      ff 35 24 98 04 08       pushl  0x8049824
   80483c6:      ff 25 28 98 04 08       jmp    *0x8049828
   80483cc:      00 00                   add    %al,(%eax)

          delete x;
   8048578:      83 ec 0c                sub    $0xc,%esp
   804857b:      ff 75 f4                pushl  0xfffffff4(%ebp)
- 804857e:      e8 4d fe ff ff          call   80483d0 <_ZdlPv@plt>
+ 804857e:      e8 4d fe ff ff          call   80483d0 <operator delete(void*)@plt>
   8048583:      83 c4 10                add    $0x10,%esp

Ciao,
Gerhard

Re: gcc and -fPIC

[Gerhard Wiesinger]

On Fri, 15 Oct 2004, Jeffrey A Law wrote:

> On Fri, 2004-10-15 at 12:51, Gerhard Wiesinger wrote:
>> On Fri, 15 Oct 2004 bserdar@nc.rr.com wrote:
>>
>>>
>>>>  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.
>>>
>>
>> OK, but why is the function call at 80485b3 to the next address at
>> 80485b8?
> Because it allows us to get the current PC's value in a position
> independent way.
>
> ie, the call pushes the return address onto the stack and we pop
> that value into ebx.
>

OK, I got it now.

Thank you.

Ciao,
Gerhard

Re: gcc and -fPIC

[Jeffrey A Law]

On Fri, 2004-10-15 at 12:51, Gerhard Wiesinger wrote:
> On Fri, 15 Oct 2004 bserdar@nc.rr.com wrote:
> 
> >
> >>  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.
> >
> 
> OK, but why is the function call at 80485b3 to the next address at 
> 80485b8?
Because it allows us to get the current PC's value in a position
independent way.

ie, the call pushes the return address onto the stack and we pop
that value into ebx.

jeff

Re: gcc and -fPIC

[bserdar]

> 
> 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
> 

Re: gcc and -fPIC

[Gerhard Wiesinger]

On Fri, 15 Oct 2004 bserdar@nc.rr.com wrote:

>
>>  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.
>

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?

Thank you for the answer.

Ciao,
Gerhard

RE: gcc and -fPIC

[Dave Korn]

> -----Original Message-----
> From: binutils-owner On Behalf Of bserdar
> Sent: 15 October 2004 19:27

> >  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.
> 

  Oh blimey, I didn't spot that.  Yes, of course that's what it's doing.
Please ignore my previous post, I would now assume that the -r flag will in
fact show that no reloc is applied nor needed on that instruction.

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Re: gcc and -fPIC

[bserdar]

>  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.