* Re: gcc and -fPIC
@ 2004-10-15 18:26 bserdar
2004-10-15 18:46 ` Dave Korn
0 siblings, 1 reply; 22+ 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] 22+ messages in thread
* RE: gcc and -fPIC
2004-10-15 18:26 gcc and -fPIC bserdar
@ 2004-10-15 18:46 ` Dave Korn
0 siblings, 0 replies; 22+ messages in thread
From: Dave Korn @ 2004-10-15 18:46 UTC (permalink / raw)
To: bserdar, 'Gerhard Wiesinger'; +Cc: binutils, gcc-help
> -----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....
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc and -fPIC
2007-04-11 5:55 Gerhard Wiesinger
@ 2007-04-13 8:21 ` Alan Modra
0 siblings, 0 replies; 22+ messages in thread
From: Alan Modra @ 2007-04-13 8:21 UTC (permalink / raw)
To: Gerhard Wiesinger; +Cc: binutils
On Wed, Apr 11, 2007 at 07:55:27AM +0200, Gerhard Wiesinger wrote:
> So is the code gcc produces (in)correct, or objdump can't read any Position
> Independent Code?
Neither. "call .+4; pop %ebx;" just loads the run-time address of the
pop insn into ebx .
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 22+ messages in thread
* gcc and -fPIC
@ 2007-04-11 5:55 Gerhard Wiesinger
2007-04-13 8:21 ` Alan Modra
0 siblings, 1 reply; 22+ messages in thread
From: Gerhard Wiesinger @ 2007-04-11 5:55 UTC (permalink / raw)
To: binutils
Hello!
Are the patches made in this thread included in the latest version of
binutils?
Thnx.
Ciao,
Gerhard
--
http://www.wiesinger.com/
-------------------------------------------------------
---------- Forwarded message ----------
Date: Fri, 15 Oct 2004 19:07:58 +0200 (CEST)
From: Gerhard Wiesinger <lists@wiesinger.com>
To: binutils@sources.redhat.com, gcc-help@gcc.gnu.org
Subject: gcc and -fPIC
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] 22+ messages in thread
* Re: gcc and -fPIC
2004-10-19 13:48 ` Andreas Schwab
@ 2004-10-20 1:14 ` Alan Modra
0 siblings, 0 replies; 22+ messages in thread
From: Alan Modra @ 2004-10-20 1:14 UTC (permalink / raw)
To: Andreas Schwab; +Cc: binutils
On Tue, Oct 19, 2004 at 03:40:05PM +0200, Andreas Schwab wrote:
> Alan Modra <amodra@bigpond.net.au> writes:
>
> > On Mon, Oct 18, 2004 at 10:11:50PM +0200, Andreas Schwab wrote:
> >> - addr = bed->plt_sym_val (i, plt, p);
> >> + addr = bed->plt_sym_val (abfd, i, plt, p);
> >
> > There's no need to pass abfd here. You can use plt->owner in your
> > target function.
>
> Hmm, I tried that first and got a segfault, but I can't reproduce that any
> more.
The only sections that can't use "owner" to access their bfd are
bfd_{abs,und,com,ind}_section. (Which is a bfd design bug IMO. See the
comment in struct bfd_symbol.)
> 2004-10-19 Andreas Schwab <schwab@suse.de>
>
> * elf32-m68k.c (elf_m68k_plt_sym_val): New fuction.
> (elf_backend_plt_sym_val): Define.
OK, thanks.
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc and -fPIC
2004-10-19 1:25 ` Alan Modra
@ 2004-10-19 13:48 ` Andreas Schwab
2004-10-20 1:14 ` Alan Modra
0 siblings, 1 reply; 22+ messages in thread
From: Andreas Schwab @ 2004-10-19 13:48 UTC (permalink / raw)
To: binutils
Alan Modra <amodra@bigpond.net.au> writes:
> On Mon, Oct 18, 2004 at 10:11:50PM +0200, Andreas Schwab wrote:
>> - addr = bed->plt_sym_val (i, plt, p);
>> + addr = bed->plt_sym_val (abfd, i, plt, p);
>
> There's no need to pass abfd here. You can use plt->owner in your
> target function.
Hmm, I tried that first and got a segfault, but I can't reproduce that any
more.
Andreas.
2004-10-19 Andreas Schwab <schwab@suse.de>
* elf32-m68k.c (elf_m68k_plt_sym_val): New fuction.
(elf_backend_plt_sym_val): Define.
Index: bfd/elf32-m68k.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-m68k.c,v
retrieving revision 1.68
diff -u -p -a -u -p -a -r1.68 bfd/elf32-m68k.c
--- bfd/elf32-m68k.c 17 Sep 2004 07:14:27 -0000 1.68
+++ bfd/elf32-m68k.c 19 Oct 2004 13:33:52 -0000
@@ -2207,6 +2207,18 @@ elf32_m68k_reloc_type_class (rela)
}
}
+/* Return address for Ith PLT stub in section PLT, for relocation REL
+ or (bfd_vma) -1 if it should not be included. */
+
+static bfd_vma
+elf_m68k_plt_sym_val (bfd_vma i, const asection *plt,
+ const arelent *rel ATTRIBUTE_UNUSED)
+{
+ if (CPU32_FLAG (plt->owner))
+ return plt->vma + (i + 1) * PLT_CPU32_ENTRY_SIZE;
+ return plt->vma + (i + 1) * PLT_ENTRY_SIZE;
+}
+
#define TARGET_BIG_SYM bfd_elf32_m68k_vec
#define TARGET_BIG_NAME "elf32-m68k"
#define ELF_MACHINE_CODE EM_68K
@@ -2236,6 +2248,7 @@ elf32_m68k_reloc_type_class (rela)
#define bfd_elf32_bfd_print_private_bfd_data \
elf32_m68k_print_private_bfd_data
#define elf_backend_reloc_type_class elf32_m68k_reloc_type_class
+#define elf_backend_plt_sym_val elf_m68k_plt_sym_val
#define elf_backend_can_gc_sections 1
#define elf_backend_can_refcount 1
--
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."
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc and -fPIC
2004-10-18 20:18 ` Andreas Schwab
@ 2004-10-19 1:25 ` Alan Modra
2004-10-19 13:48 ` Andreas Schwab
0 siblings, 1 reply; 22+ messages in thread
From: Alan Modra @ 2004-10-19 1:25 UTC (permalink / raw)
To: Andreas Schwab; +Cc: binutils
On Mon, Oct 18, 2004 at 10:11:50PM +0200, Andreas Schwab wrote:
> - addr = bed->plt_sym_val (i, plt, p);
> + addr = bed->plt_sym_val (abfd, i, plt, p);
There's no need to pass abfd here. You can use plt->owner in your
target function.
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc and -fPIC
2004-10-16 15:17 ` Daniel Jacobowitz
2004-10-17 18:57 ` Gerhard Wiesinger
@ 2004-10-18 20:18 ` Andreas Schwab
2004-10-19 1:25 ` Alan Modra
1 sibling, 1 reply; 22+ messages in thread
From: Andreas Schwab @ 2004-10-18 20:18 UTC (permalink / raw)
To: binutils
Daniel Jacobowitz <drow@false.org> writes:
> 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.
Didn't work on m68k.
Tested on ppc-linux with target=m68k-linux, enable-targets=all and
enable-64-bit-bfd, no new warnings, no regressions.
Andreas.
2004-10-18 Andreas Schwab <schwab@suse.de>
* elf-bfd.h (struct elf_backend_data): Change plt_sym_val to take
pointer to bfd as additional first parameter.
* elf.c (_bfd_elf_get_synthetic_symtab): Pass abfd to plt_sym_val.
* elf32-i386.c (elf_i386_plt_sym_val): Update argument list.
* elf32-ppc.c (ppc_elf_plt_sym_val): Likewise.
* elf32-s390.c (elf_s390_plt_sym_val): Likewise.
* elf32-sh.c (sh_elf_plt_sym_val): Likewise.
* elf32-sparc.c (elf32_sparc_plt_sym_val): Likewise.
* elf64-s390.c (elf_s390_plt_sym_val): Likewise.
* elf64-sparc.c (sparc64_elf_plt_sym_val): Likewise.
* elf64-x86-64.c (elf64_x86_64_plt_sym_val): Likewise.
* elf32-m68k.c (elf_m68k_plt_sym_val): New function.
(elf_backend_plt_sym_val): Define.
Index: bfd/elf-bfd.h
===================================================================
RCS file: /cvs/src/src/bfd/elf-bfd.h,v
retrieving revision 1.162
diff -u -p -a -r1.162 elf-bfd.h
--- bfd/elf-bfd.h 14 Oct 2004 23:38:08 -0000 1.162
+++ bfd/elf-bfd.h 18 Oct 2004 19:59:30 -0000
@@ -943,7 +943,8 @@ struct elf_backend_data
/* This function is used by `_bfd_elf_get_synthetic_symtab';
see elf.c. */
- bfd_vma (*plt_sym_val) (bfd_vma, const asection *, const arelent *);
+ bfd_vma (*plt_sym_val) (bfd *abfd, bfd_vma, const asection *,
+ const arelent *);
/* Used to handle bad SHF_LINK_ORDER input. */
bfd_error_handler_type link_order_error_handler;
Index: bfd/elf.c
===================================================================
RCS file: /cvs/src/src/bfd/elf.c,v
retrieving revision 1.251
diff -u -p -a -r1.251 elf.c
--- bfd/elf.c 14 Oct 2004 23:38:08 -0000 1.251
+++ bfd/elf.c 18 Oct 2004 19:59:30 -0000
@@ -7851,7 +7851,7 @@ _bfd_elf_get_synthetic_symtab (bfd *abfd
size_t len;
bfd_vma addr;
- addr = bed->plt_sym_val (i, plt, p);
+ addr = bed->plt_sym_val (abfd, i, plt, p);
if (addr == (bfd_vma) -1)
continue;
Index: bfd/elf32-i386.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-i386.c,v
retrieving revision 1.129
diff -u -p -a -r1.129 elf32-i386.c
--- bfd/elf32-i386.c 17 Sep 2004 07:14:26 -0000 1.129
+++ bfd/elf32-i386.c 18 Oct 2004 19:59:30 -0000
@@ -3279,7 +3279,8 @@ elf_i386_finish_dynamic_sections (bfd *o
or (bfd_vma) -1 if it should not be included. */
static bfd_vma
-elf_i386_plt_sym_val (bfd_vma i, const asection *plt,
+elf_i386_plt_sym_val (bfd *abfd ATTRIBUTE_UNUSED,
+ bfd_vma i, const asection *plt,
const arelent *rel ATTRIBUTE_UNUSED)
{
return plt->vma + (i + 1) * PLT_ENTRY_SIZE;
Index: bfd/elf32-m68k.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-m68k.c,v
retrieving revision 1.68
diff -u -p -a -r1.68 elf32-m68k.c
--- bfd/elf32-m68k.c 17 Sep 2004 07:14:27 -0000 1.68
+++ bfd/elf32-m68k.c 18 Oct 2004 19:59:30 -0000
@@ -2207,6 +2207,18 @@ elf32_m68k_reloc_type_class (rela)
}
}
+/* Return address for Ith PLT stub in section PLT, for relocation REL
+ or (bfd_vma) -1 if it should not be included. */
+
+static bfd_vma
+elf_m68k_plt_sym_val (bfd *abfd, bfd_vma i, const asection *plt,
+ const arelent *rel ATTRIBUTE_UNUSED)
+{
+ if (CPU32_FLAG (abfd))
+ return plt->vma + (i + 1) * PLT_CPU32_ENTRY_SIZE;
+ return plt->vma + (i + 1) * PLT_ENTRY_SIZE;
+}
+
#define TARGET_BIG_SYM bfd_elf32_m68k_vec
#define TARGET_BIG_NAME "elf32-m68k"
#define ELF_MACHINE_CODE EM_68K
@@ -2236,6 +2248,7 @@ elf32_m68k_reloc_type_class (rela)
#define bfd_elf32_bfd_print_private_bfd_data \
elf32_m68k_print_private_bfd_data
#define elf_backend_reloc_type_class elf32_m68k_reloc_type_class
+#define elf_backend_plt_sym_val elf_m68k_plt_sym_val
#define elf_backend_can_gc_sections 1
#define elf_backend_can_refcount 1
Index: bfd/elf32-ppc.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-ppc.c,v
retrieving revision 1.128
diff -u -p -a -r1.128 elf32-ppc.c
--- bfd/elf32-ppc.c 10 Oct 2004 13:58:05 -0000 1.128
+++ bfd/elf32-ppc.c 18 Oct 2004 19:59:31 -0000
@@ -6138,7 +6138,8 @@ ppc_elf_final_write_processing (bfd *abf
or (bfd_vma) -1 if it should not be included. */
static bfd_vma
-ppc_elf_plt_sym_val (bfd_vma i ATTRIBUTE_UNUSED,
+ppc_elf_plt_sym_val (bfd *abfd ATTRIBUTE_UNUSED,
+ bfd_vma i ATTRIBUTE_UNUSED,
const asection *plt ATTRIBUTE_UNUSED,
const arelent *rel)
{
Index: bfd/elf32-s390.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-s390.c,v
retrieving revision 1.66
diff -u -p -a -r1.66 elf32-s390.c
--- bfd/elf32-s390.c 17 Sep 2004 07:14:28 -0000 1.66
+++ bfd/elf32-s390.c 18 Oct 2004 19:59:31 -0000
@@ -3450,7 +3450,8 @@ elf_s390_grok_prstatus (abfd, note)
or (bfd_vma) -1 if it should not be included. */
static bfd_vma
-elf_s390_plt_sym_val (bfd_vma i, const asection *plt,
+elf_s390_plt_sym_val (bfd *abfd ATTRIBUTE_UNUSED,
+ bfd_vma i, const asection *plt,
const arelent *rel ATTRIBUTE_UNUSED)
{
return plt->vma + PLT_FIRST_ENTRY_SIZE + i * PLT_ENTRY_SIZE;
Index: bfd/elf32-sh.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-sh.c,v
retrieving revision 1.115
diff -u -p -a -r1.115 elf32-sh.c
--- bfd/elf32-sh.c 17 Sep 2004 07:14:28 -0000 1.115
+++ bfd/elf32-sh.c 18 Oct 2004 19:59:31 -0000
@@ -7454,7 +7454,8 @@ elf32_shlin_grok_psinfo (bfd *abfd, Elf_
or (bfd_vma) -1 if it should not be included. */
static bfd_vma
-sh_elf_plt_sym_val (bfd_vma i, const asection *plt,
+sh_elf_plt_sym_val (bfd *abfd ATTRIBUTE_UNUSED,
+ bfd_vma i, const asection *plt,
const arelent *rel ATTRIBUTE_UNUSED)
{
return plt->vma + (i + 1) * PLT_ENTRY_SIZE;
Index: bfd/elf32-sparc.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-sparc.c,v
retrieving revision 1.75
diff -u -p -a -r1.75 elf32-sparc.c
--- bfd/elf32-sparc.c 23 Sep 2004 00:51:33 -0000 1.75
+++ bfd/elf32-sparc.c 18 Oct 2004 19:59:31 -0000
@@ -3420,7 +3420,8 @@ elf32_sparc_reloc_type_class (rela)
or (bfd_vma) -1 if it should not be included. */
static bfd_vma
-elf32_sparc_plt_sym_val (bfd_vma i ATTRIBUTE_UNUSED,
+elf32_sparc_plt_sym_val (bfd *abfd ATTRIBUTE_UNUSED,
+ bfd_vma i ATTRIBUTE_UNUSED,
const asection *plt ATTRIBUTE_UNUSED,
const arelent *rel)
{
Index: bfd/elf64-s390.c
===================================================================
RCS file: /cvs/src/src/bfd/elf64-s390.c,v
retrieving revision 1.66
diff -u -p -a -r1.66 elf64-s390.c
--- bfd/elf64-s390.c 17 Sep 2004 07:14:29 -0000 1.66
+++ bfd/elf64-s390.c 18 Oct 2004 19:59:31 -0000
@@ -3360,7 +3360,8 @@ elf_s390_finish_dynamic_sections (output
or (bfd_vma) -1 if it should not be included. */
static bfd_vma
-elf_s390_plt_sym_val (bfd_vma i, const asection *plt,
+elf_s390_plt_sym_val (bfd *abfd ATTRIBUTE_UNUSED,
+ bfd_vma i, const asection *plt,
const arelent *rel ATTRIBUTE_UNUSED)
{
return plt->vma + PLT_FIRST_ENTRY_SIZE + i * PLT_ENTRY_SIZE;
Index: bfd/elf64-sparc.c
===================================================================
RCS file: /cvs/src/src/bfd/elf64-sparc.c,v
retrieving revision 1.96
diff -u -p -a -r1.96 elf64-sparc.c
--- bfd/elf64-sparc.c 17 Sep 2004 07:14:30 -0000 1.96
+++ bfd/elf64-sparc.c 18 Oct 2004 19:59:31 -0000
@@ -3096,7 +3096,8 @@ sparc64_elf_object_p (abfd)
or (bfd_vma) -1 if it should not be included. */
static bfd_vma
-sparc64_elf_plt_sym_val (bfd_vma i, const asection *plt,
+sparc64_elf_plt_sym_val (bfd *abfd ATTRIBUTE_UNUSED,
+ bfd_vma i, const asection *plt,
const arelent *rel ATTRIBUTE_UNUSED)
{
bfd_vma j;
Index: bfd/elf64-x86-64.c
===================================================================
RCS file: /cvs/src/src/bfd/elf64-x86-64.c,v
retrieving revision 1.86
diff -u -p -a -r1.86 elf64-x86-64.c
--- bfd/elf64-x86-64.c 8 Oct 2004 13:54:57 -0000 1.86
+++ bfd/elf64-x86-64.c 18 Oct 2004 19:59:31 -0000
@@ -2776,7 +2776,8 @@ elf64_x86_64_finish_dynamic_sections (bf
or (bfd_vma) -1 if it should not be included. */
static bfd_vma
-elf64_x86_64_plt_sym_val (bfd_vma i, const asection *plt,
+elf64_x86_64_plt_sym_val (bfd *abfd ATTRIBUTE_UNUSED,
+ bfd_vma i, const asection *plt,
const arelent *rel ATTRIBUTE_UNUSED)
{
return plt->vma + (i + 1) * PLT_ENTRY_SIZE;
--
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."
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc and -fPIC
2004-10-18 8:29 ` Hans-Peter Nilsson
@ 2004-10-18 12:35 ` Alan Modra
0 siblings, 0 replies; 22+ messages in thread
From: Alan Modra @ 2004-10-18 12:35 UTC (permalink / raw)
To: Hans-Peter Nilsson; +Cc: binutils
On Mon, Oct 18, 2004 at 04:29:09AM -0400, Hans-Peter Nilsson wrote:
> Would it be ok to handle ":" this way as well?
> (It's used for CRIS, because '@' is a line-terminator.)
Yes, I think it would be reasonable.
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc and -fPIC
2004-10-18 7:09 ` Alan Modra
2004-10-18 7:26 ` Alan Modra
@ 2004-10-18 8:29 ` Hans-Peter Nilsson
2004-10-18 12:35 ` Alan Modra
1 sibling, 1 reply; 22+ messages in thread
From: Hans-Peter Nilsson @ 2004-10-18 8:29 UTC (permalink / raw)
To: Alan Modra; +Cc: binutils
On Mon, 18 Oct 2004, Alan Modra wrote:
> On Mon, Oct 18, 2004 at 07:17:43AM +0200, Gerhard Wiesinger wrote:
> > As I specified the -C switch
> > (demangle C++) I would expect that this is demangled too.
>
> So would I.
>
> * budemang.c (demangle): Handle "@plt" suffix.
Would it be ok to handle ":" this way as well?
(It's used for CRIS, because '@' is a line-terminator.)
(Heh, maybe even a target hook... Nah, I didn't say that. ;-)
brgds, H-P
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc and -fPIC
2004-10-18 7:26 ` Alan Modra
@ 2004-10-18 7:55 ` Gerhard Wiesinger
0 siblings, 0 replies; 22+ messages in thread
From: Gerhard Wiesinger @ 2004-10-18 7:55 UTC (permalink / raw)
To: Alan Modra; +Cc: binutils
OK, looks good.
Thank you for the fast response!!!
Ciao,
Gerhard
On Mon, 18 Oct 2004, Alan Modra wrote:
> On Mon, Oct 18, 2004 at 04:39:33PM +0930, Alan Modra wrote:
>> * budemang.c (demangle): Handle "@plt" suffix.
>
> Test first, then commit. Test first, ...
>
> * budemang.c (demangle): Fix thinko.
>
> Index: binutils/budemang.c
> ===================================================================
> RCS file: /cvs/src/src/binutils/budemang.c,v
> retrieving revision 1.5
> diff -u -p -r1.5 budemang.c
> --- binutils/budemang.c 18 Oct 2004 07:08:52 -0000 1.5
> +++ binutils/budemang.c 18 Oct 2004 07:25:05 -0000
> @@ -52,7 +52,7 @@ demangle (bfd *abfd, const char *name)
> pre = name;
> while (*name == '.')
> ++name;
> - pre_len = pre - name;
> + pre_len = name - pre;
>
> alloc = NULL;
> suf = strchr (name, '@');
>
> --
> Alan Modra
> IBM OzLabs - Linux Technology Centre
>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc and -fPIC
2004-10-18 7:09 ` Alan Modra
@ 2004-10-18 7:26 ` Alan Modra
2004-10-18 7:55 ` Gerhard Wiesinger
2004-10-18 8:29 ` Hans-Peter Nilsson
1 sibling, 1 reply; 22+ messages in thread
From: Alan Modra @ 2004-10-18 7:26 UTC (permalink / raw)
To: Gerhard Wiesinger, binutils
On Mon, Oct 18, 2004 at 04:39:33PM +0930, Alan Modra wrote:
> * budemang.c (demangle): Handle "@plt" suffix.
Test first, then commit. Test first, ...
* budemang.c (demangle): Fix thinko.
Index: binutils/budemang.c
===================================================================
RCS file: /cvs/src/src/binutils/budemang.c,v
retrieving revision 1.5
diff -u -p -r1.5 budemang.c
--- binutils/budemang.c 18 Oct 2004 07:08:52 -0000 1.5
+++ binutils/budemang.c 18 Oct 2004 07:25:05 -0000
@@ -52,7 +52,7 @@ demangle (bfd *abfd, const char *name)
pre = name;
while (*name == '.')
++name;
- pre_len = pre - name;
+ pre_len = name - pre;
alloc = NULL;
suf = strchr (name, '@');
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc and -fPIC
2004-10-18 5:18 ` Gerhard Wiesinger
@ 2004-10-18 7:09 ` Alan Modra
2004-10-18 7:26 ` Alan Modra
2004-10-18 8:29 ` Hans-Peter Nilsson
0 siblings, 2 replies; 22+ messages in thread
From: Alan Modra @ 2004-10-18 7:09 UTC (permalink / raw)
To: Gerhard Wiesinger; +Cc: binutils
On Mon, Oct 18, 2004 at 07:17:43AM +0200, Gerhard Wiesinger wrote:
> As I specified the -C switch
> (demangle C++) I would expect that this is demangled too.
So would I.
* budemang.c (demangle): Handle "@plt" suffix.
Index: binutils/budemang.c
===================================================================
RCS file: /cvs/src/src/binutils/budemang.c,v
retrieving revision 1.4
diff -u -p -r1.4 budemang.c
--- binutils/budemang.c 14 Sep 2003 12:20:16 -0000 1.4
+++ binutils/budemang.c 18 Oct 2004 06:49:52 -0000
@@ -38,8 +38,9 @@
char *
demangle (bfd *abfd, const char *name)
{
- char *res;
- const char *p;
+ char *res, *alloc;
+ const char *pre, *suf;
+ size_t pre_len;
if (abfd != NULL && bfd_get_symbol_leading_char (abfd) == name[0])
++name;
@@ -48,28 +49,52 @@ demangle (bfd *abfd, const char *name)
or the MS PE format. These formats have a number of leading '.'s
on at least some symbols, so we remove all dots to avoid
confusing the demangler. */
- p = name;
- while (*p == '.')
- ++p;
+ pre = name;
+ while (*name == '.')
+ ++name;
+ pre_len = pre - name;
- res = cplus_demangle (p, DMGL_ANSI | DMGL_PARAMS);
- if (res)
+ alloc = NULL;
+ suf = strchr (name, '@');
+ if (suf != NULL)
{
- size_t dots = p - name;
+ alloc = xmalloc (suf - name + 1);
+ memcpy (alloc, name, suf - name);
+ alloc[suf - name] = '\0';
+ name = alloc;
+ }
- /* Now put back any stripped dots. */
- if (dots != 0)
+ res = cplus_demangle (name, DMGL_ANSI | DMGL_PARAMS);
+ if (res != NULL)
+ {
+ /* Now put back any suffix, or stripped dots. */
+ if (pre_len != 0 || suf != NULL)
{
- size_t len = strlen (res) + 1;
- char *add_dots = xmalloc (len + dots);
-
- memcpy (add_dots, name, dots);
- memcpy (add_dots + dots, res, len);
+ size_t len;
+ size_t suf_len;
+ char *final;
+
+ if (alloc != NULL)
+ free (alloc);
+
+ len = strlen (res);
+ if (suf == NULL)
+ suf = res + len;
+ suf_len = strlen (suf) + 1;
+ final = xmalloc (pre_len + len + suf_len);
+
+ memcpy (final, pre, pre_len);
+ memcpy (final + pre_len, res, len);
+ memcpy (final + pre_len + len, suf, suf_len);
free (res);
- res = add_dots;
+ res = final;
}
+
return res;
}
- return xstrdup (name);
+ if (alloc != NULL)
+ free (alloc);
+
+ return xstrdup (pre);
}
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc and -fPIC
2004-10-17 19:31 ` Daniel Jacobowitz
@ 2004-10-18 5:18 ` Gerhard Wiesinger
2004-10-18 7:09 ` Alan Modra
0 siblings, 1 reply; 22+ messages in thread
From: Gerhard Wiesinger @ 2004-10-18 5:18 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: Andreas Schwab, binutils, gcc-help
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc and -fPIC
2004-10-17 18:57 ` Gerhard Wiesinger
@ 2004-10-17 19:31 ` Daniel Jacobowitz
2004-10-18 5:18 ` Gerhard Wiesinger
0 siblings, 1 reply; 22+ messages in thread
From: Daniel Jacobowitz @ 2004-10-17 19:31 UTC (permalink / raw)
To: Gerhard Wiesinger; +Cc: Andreas Schwab, binutils, gcc-help
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc and -fPIC
2004-10-16 15:17 ` Daniel Jacobowitz
@ 2004-10-17 18:57 ` Gerhard Wiesinger
2004-10-17 19:31 ` Daniel Jacobowitz
2004-10-18 20:18 ` Andreas Schwab
1 sibling, 1 reply; 22+ messages in thread
From: Gerhard Wiesinger @ 2004-10-17 18:57 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: Andreas Schwab, binutils, gcc-help
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc and -fPIC
2004-10-16 12:09 ` Andreas Schwab
@ 2004-10-16 15:17 ` Daniel Jacobowitz
2004-10-17 18:57 ` Gerhard Wiesinger
2004-10-18 20:18 ` Andreas Schwab
0 siblings, 2 replies; 22+ messages in thread
From: Daniel Jacobowitz @ 2004-10-16 15:17 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Gerhard Wiesinger, binutils, gcc-help
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc and -fPIC
2004-10-16 6:06 ` Gerhard Wiesinger
@ 2004-10-16 12:09 ` Andreas Schwab
2004-10-16 15:17 ` Daniel Jacobowitz
0 siblings, 1 reply; 22+ messages in thread
From: Andreas Schwab @ 2004-10-16 12:09 UTC (permalink / raw)
To: Gerhard Wiesinger; +Cc: binutils, gcc-help
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."
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc and -fPIC
2004-10-15 19:55 ` Andreas Schwab
@ 2004-10-16 6:06 ` Gerhard Wiesinger
2004-10-16 12:09 ` Andreas Schwab
0 siblings, 1 reply; 22+ messages in thread
From: Gerhard Wiesinger @ 2004-10-16 6:06 UTC (permalink / raw)
To: Andreas Schwab; +Cc: binutils, gcc-help
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc and -fPIC
2004-10-15 17:08 Gerhard Wiesinger
2004-10-15 17:54 ` Dave Korn
@ 2004-10-15 19:55 ` Andreas Schwab
2004-10-16 6:06 ` Gerhard Wiesinger
1 sibling, 1 reply; 22+ messages in thread
From: Andreas Schwab @ 2004-10-15 19:55 UTC (permalink / raw)
To: Gerhard Wiesinger; +Cc: binutils, gcc-help
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."
^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: gcc and -fPIC
2004-10-15 17:08 Gerhard Wiesinger
@ 2004-10-15 17:54 ` Dave Korn
2004-10-15 19:55 ` Andreas Schwab
1 sibling, 0 replies; 22+ messages in thread
From: Dave Korn @ 2004-10-15 17:54 UTC (permalink / raw)
To: 'Gerhard Wiesinger', binutils, gcc-help
> -----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....
^ permalink raw reply [flat|nested] 22+ messages in thread
* 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; 22+ 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] 22+ messages in thread
end of thread, other threads:[~2007-04-13 7:48 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-10-15 18:26 gcc and -fPIC bserdar
2004-10-15 18:46 ` Dave Korn
-- strict thread matches above, loose matches on Subject: below --
2007-04-11 5:55 Gerhard Wiesinger
2007-04-13 8:21 ` Alan Modra
2004-10-15 17:08 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:18 ` Gerhard Wiesinger
2004-10-18 7:09 ` Alan Modra
2004-10-18 7:26 ` Alan Modra
2004-10-18 7:55 ` Gerhard Wiesinger
2004-10-18 8:29 ` Hans-Peter Nilsson
2004-10-18 12:35 ` Alan Modra
2004-10-18 20:18 ` Andreas Schwab
2004-10-19 1:25 ` Alan Modra
2004-10-19 13:48 ` Andreas Schwab
2004-10-20 1:14 ` Alan Modra
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).