This is the mail archive of the
mailing list for the GCC project.
Re: MSVC hook function prologue
- From: Paolo Bonzini <bonzini at gnu dot org>
- To: Stefan Dösinger <stefan at codeweavers dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Thu, 03 Sep 2009 00:04:43 +0200
- Subject: Re: MSVC hook function prologue
- References: <firstname.lastname@example.org>
Currently I still have these problems:
*) There is apparently some plugin framework in the works. Can this
functionality implemented as a plugin?
No, plugins do not affect the backend.
*) The stack alignment code + msvc_prologue is used by Wine on osx though.
Currently I pop %ebp after the 5 byte prologue, and the normal code recreates
the frame pointer afterwards. My understanding is that I can avoid this by
keeping the original frame pointer, but adjusting a lot of offsets after the
alignment to find the function parameters and align the stack properly on
calls. However, this is currently above my head.
I don't think this would prevent the patch from getting the patch in.
*) What other changes are needed to get a functionality like this into
I think right now I'd make only two cosmetic adjustments:
- warning (OPT_Wattributes, "%qE attribute only available for 64-bit",
- *no_add_attrs = true;
- return NULL_TREE;
+ if(!is_attribute_p ("msvc_prologue", name))
? !is_attribute_p ("msvc_prologue", name))
: is_attribute_p ("msvc_prologue", name))
warning (OPT_Wattributes, "%qE attribute not available for "
"%d-bit", name, TARGET_64BIT ? 64 : 32);
*no_add_attrs = true;
+[(unspec_volatile [(match_operand 0 "register_operand" "0")
+ (match_operand 1 "register_operand" "1")]
+ UNSPECV_VSWAPMOV )]
I'd try defining the insn as
[(set (match_operand 0 "register_operand" "0")
(match_operand 1 "register_operand" "1")
(unspec_volatile  UNSPECV_VSWAPMOV)]
I think this should work and would be nicer to the compiler's dataflow
analysis, but it should be tested of course.
I'm not an x86 maintainer, though.