public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/16030] New: [cygwin/mingw]: stdcall function decoration vs LTHUNK alias in multiple inheritanc
@ 2004-06-17  2:53 dannysmith at users dot sourceforge dot net
  2004-07-07  1:04 ` [Bug c++/16030] " dannysmith at users dot sourceforge dot net
                   ` (13 more replies)
  0 siblings, 14 replies; 15+ messages in thread
From: dannysmith at users dot sourceforge dot net @ 2004-06-17  2:53 UTC (permalink / raw)
  To: gcc-bugs

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


^ permalink raw reply	[flat|nested] 15+ messages in thread
end of thread, other threads:[~2005-05-19 17:27 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-06-17  2:53 [Bug c++/16030] New: [cygwin/mingw]: stdcall function decoration vs LTHUNK alias in multiple inheritanc dannysmith at users dot sourceforge dot net
2004-07-07  1:04 ` [Bug c++/16030] " dannysmith at users dot sourceforge dot net
2004-07-07  1:07 ` [Bug c++/16030] [3.4/3.5 Regression] " pinskia at gcc dot gnu dot org
2004-08-12  8:15 ` steven at gcc dot gnu dot org
2004-08-12 14:35 ` mark at codesourcery dot com
2004-08-18 10:07 ` dannysmith at users dot sourceforge dot net
2004-08-19 21:21 ` mmitchel at gcc dot gnu dot org
2004-08-21  8:02 ` cvs-commit at gcc dot gnu dot org
2004-08-21  8:05 ` [Bug c++/16030] [3.4 " dannysmith at users dot sourceforge dot net
2004-08-23  6:54 ` mark at codesourcery dot com
2004-08-29 18:53 ` mmitchel at gcc dot gnu dot org
2004-10-31  2:01 ` mmitchel at gcc dot gnu dot org
2004-10-31  2:05 ` giovannibajo at libero dot it
2004-10-31  2:37 ` dannysmith at users dot sourceforge dot net
2005-05-19 17:27 ` mmitchel at gcc dot gnu dot org

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).