This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/14808] [3.4/3.5 Regression] [win32] Undefined results with virtual base classes


------- Additional Comments From dannysmith at users dot sourceforge dot net  2004-04-05 21:59 -------
Hello

I suspect that this bug is due to the way that the PE-COFF emulation of
GNU ld handles linkonce sections.  Specifically, ld does not reliably
handle linkonce sections contining more than one global symbol. For
example, this assembler code also produces a faulting app:

	.file	"bar2.c"
	.def	___main;	.scl	2;	.type	32;	.endef
	.text
	.align 2
.globl _main
	.def	_main;	.scl	2;	.type	32;	.endef
_main:
	pushl	%ebp
	movl	%esp, %ebp
	subl	$8, %esp
	andl	$-16, %esp
	movl	$16, %eax
	call	__alloca
	call	___main
	call	__Z3onev
	call	__Z8call_onev
	leave
	.p2align 4,,4
	ret
	.section	.text$_Z8call_onev,"x"
	.linkonce discard
	.align 2
.globl __Z8call_onev
	.def	__Z8call_onev;	.scl	2;	.type	32;	.endef
__Z8call_onev:
	subl	$12, %esp
	call	__Z3onev
	addl	$12, %esp
	ret
#	.section	.text$_Z3onev,"x"
#	.linkonce discard
	.align 2
.globl __Z3onev
	.def	__Z3onev;	.scl	2;	.type	32;	.endef
__Z3onev:
	movl	$1, %eax
	ret

but is okay if I put the the the two functions in separate .linkonce sections,

Referring to the testcase in my first comments for this PR, if the
virtual function in the derived class is not inlined, and so does not
use linkonce semantics, then the app built from the modified testcase
executes correctly. Likewise, if I comment out this code in cp/method,c
(use_thunk)

*** method.c.orig	Mon Apr 05 21:49:30 2004
--- method.c	Mon Apr 05 00:41:59 2004
*************** use_thunk (tree thunk_fndecl, bool emit_
*** 409,416 ****
--- 409,418 ----
        if (DECL_SECTION_NAME (function) != NULL && DECL_ONE_ONLY (function))
  	{
  	  resolve_unique_section (thunk_fndecl, 0, flag_function_sections);
+ #if !(defined (__MINGW32__ ) || defined (__CYGWIN__))
  	  /* Output the thunk into the same section as function.  */
  	  DECL_SECTION_NAME (thunk_fndecl) = DECL_SECTION_NAME (function);
+ #endif
  	}
      }
  #endif

the app is okay.

But, as indicated by Jakub when the local aliases for virtual thunks code was
introduced

http://gcc.gnu.org/ml/gcc-patches/2003-06/msg02603.html

"If a method is emitted in a linkonce section, it will emit the thunk into
 the same linkonce section as well, since local symbols in linkonce sections
 cannot be safely accessed from other sections."

this is not really a safe thing to do.

Should _all_ the make_alias_for_thunk code in method.c be guarded by a
target macro (e.g. TARGET_USE_LOCAL_ALIAS_FOR_VTHUNK), which defaults to
1 #ifdef ASM_OUTPUT_DEF, but can be overriden by targets which define
ASM_OUTPUT_DEF, but may currently have problems with multiple globals in
linkonce sections?

Danny

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at redhat dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14808


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]