A serious gas/gld bug

[Jason Merrill]

>>>>> H J Lu <hjl@nynexst.com> writes:

> It is gas/gld who clobbered ebx which is used by 'i'. Here is the test
> case. Jason, could you please verify gas/gld on x86 UnixWare? I am
> curious why you didn't see problem on x86 UnixWare.

They seem to work properly on x86 Unixware.

> It seems that gas/gld cannot handle

> 	.section	.fini/.init

> right. As you can see from objdump --disassemble,

> fini_dummy:
> 	.section        .fini
> 	call __do_global_dtors_aux

> becomes

> 	call __do_global_dtors_aux+2

Hmm.  On UnixWare, it becomes

Disassembly of section .fini:
	call 00000001 <__DTOR_LIST__+1>

which I assume is a reference to the first relocation entry for .fini:

RELOCATION RECORDS FOR [.fini]:
OFFSET   TYPE              VALUE 
00000001 R_386_PLT32       __do_global_dtors_aux

Are there two relocation entries for .fini under Linux-ELF?

> At the final linking, a.out.asm, you can see it become

> 	call __do_global_dtors_aux+1

On UnixWare, the link creating the shared library fixes up the reference to
be an actual call to the function.  It does not seem to be off by one.

objdump -xd libg++.so
...
SYMBOL TABLE:
...
000672f4 l       .text  __do_global_ctors_aux
...
0001eadc l       .text  __do_global_dtors_aux
...
Disassembly of section .init:
0001cc14 <_init> call   000672f4 <__do_global_ctors_aux>
0001cc19 <_init+5> ret    $0x0
...
Disassembly of section .fini:
00067350 <_fini> call   0001eadc <__do_global_dtors_aux>
00067355 <_fini+5> ret    $0x0
...

> Similar thing also happens to __do_global_ctors_aux. That screwed up
> everything since it skip the very importmant

> 	push	%ebx

Did this happen when you were stepping through at runtime?

Jason