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++/16030] New: [cygwin/mingw]: stdcall function decoration vs LTHUNK alias in multiple inheritanc


The  decoration of stdcall symbols in winnt.c:i386_pe_encode_section_info
causesa problems with the use of static aliases for MI thunks in
cp/method.c 

This problem is in 3.4.1 and trunk.

Consider this testcase:

// stdcall_thunk.C
class  MBase
{
public:
  virtual int __attribute__((stdcall)) vf() const = 0;
  virtual ~MBase() {};
};

class D1 : virtual public MBase
{
public:
  int __attribute__((stdcall)) vf() const;
};

class M1: public D1
{
public:
  int __attribute__((stdcall)) vf() const;
};

int D1::vf() const { return 1; }
int M1::vf() const { return D1::vf();}


This produces the assembly:

	.file	"stdcall_thunk.C"
	.def	LTHUNK0@4;	.scl	3;	.type	32;	.endef
	.set	LTHUNK0@4,__ZNK2D12vfEv  <<< not decorated

[...]

.globl __ZNK2D12vfEv@4  <<< stdcall decoration
	.def	__ZNK2D12vfEv@4;	.scl	2;	.type	32;	.endef
__ZNK2D12vfEv@4: 
	pushl	%ebp
	movl	%esp, %ebp
	movl	$1, %eax
	leave
	ret	$4
[...]


Note that although the D1::vf name has the correct stdcall decoaration,
the target of LTHUNK0@4 does not.

Although ld actually has an option to fix-up stdcall symbols to
the undecorated name, using that option can mask stack corruption bugs
until the app is actually run.

One way to fix is to use the RTL name rather than DECL_ASSEMBLER_NAME in
make alias_for_thunk, ie:

Index: method.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/method.c,v
retrieving revision 1.285
diff -c -3 -p -r1.285 method.c
*** method.c	16 Jun 2004 01:21:31 -0000	1.285
--- method.c	17 Jun 2004 02:41:09 -0000
*************** make_alias_for_thunk (tree function)
*** 314,320 ****
    SET_DECL_ASSEMBLER_NAME (alias, DECL_NAME (alias));
    TREE_SYMBOL_REFERENCED (DECL_ASSEMBLER_NAME (alias)) = 1;
    if (!flag_syntax_only)
!     assemble_alias (alias, DECL_ASSEMBLER_NAME (function));
    return alias;
  }
  
--- 314,330 ----
    SET_DECL_ASSEMBLER_NAME (alias, DECL_NAME (alias));
    TREE_SYMBOL_REFERENCED (DECL_ASSEMBLER_NAME (alias)) = 1;
    if (!flag_syntax_only)
!     {
!       /* Using DECL_ASSEMBLER_NAME to get the identifier for the alias
! 	 target loses any decoration that targetm.encode_section_info
! 	 may have added.  Use the RTL name instead.  */
!       tree idp;
!       /* Is this necessary?  */
!       if (!DECL_RTL_SET_P (function))
! 	make_decl_rtl (function, NULL);
!       idp = get_identifier (XSTR (XEXP (DECL_RTL (function), 0), 0));
!       assemble_alias (alias, idp);
!     }
    return alias;
  }
  


With above patch, I get this:

	.file	"stdcall_thunk.C"
	.def	LTHUNK0@4;	.scl	3;	.type	32;	.endef
	.set	LTHUNK0@4,__ZNK2D12vfEv@4  <<< OK

[...]

.globl __ZNK2D12vfEv@4
	.def	__ZNK2D12vfEv@4;	.scl	2;	.type	32;	.endef
__ZNK2D12vfEv@4:
	pushl	%ebp
	movl	%esp, %ebp
	movl	$1, %eax
	leave
	ret	$4


Is there a better way to do this?

Danny

-- 
           Summary: [cygwin/mingw]: stdcall function decoration vs LTHUNK
                    alias in multiple inheritanc
           Product: gcc
           Version: 3.4.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: dannysmith at users dot sourceforge dot net
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-mingw32
  GCC host triplet: i686-pc-mingw32
GCC target triplet: i686-pc-mingw32


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


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