This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/14808] [3.4/3.5 Regression] [win32] Undefined results with virtual base classes
- From: "dannysmith at users dot sourceforge dot net" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 5 Apr 2004 21:59:32 -0000
- Subject: [Bug c++/14808] [3.4/3.5 Regression] [win32] Undefined results with virtual base classes
- References: <20040401090427.14808.dannysmith@users.sourceforge.net>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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