Inserting code into prologue/epilogue
/*/ x = cfun->machine->force_align_arg_pointer; x = gen_frame_mem (Pmode, plus_constant (x, -8)) xor hard_frame_pointer_rtx; insn = emit_insn (gen_push (x)); RTX_FRAME_RELATED_P (insn) = 1; /*/ I am trying to push a copy of return address just below the return address and xor it with the "frame pointer". I wanted to know if the above code is correct for pushing the return address and encrypt it with the frame pointer. Now, in the epilogue I want to decrypt this copy of return address with the pushed frame pointer and verify if the two instances (original and decrypted) of the return address are same. This is the first time I am working on an approach that requires to make modifications to the ix86_expand_prologue/epilogue methods of the compiler. I also wanted to know how to read the value of encrypted return address in the ix86_expand_epilogue method, since then I need to decrypt it and compare it with the original return address pushed on the stack. -- Vaibhav Shrimali BTech(ICT), DA-IICT Gandhinagar, INDIA
Re: Fwd: constant hoisting out of loops
On Sun, Mar 21, 2010 at 3:43 AM, Jim Wilson wrote: > On Sun, 2010-03-21 at 03:40 +0800, fanqifei wrote: >> foor_expand_move is changed and it works now. >> However, I still don't understand why there was no such error if below >> condition was used and foor_expand_move was not changed. >> Both below condition and "(register_operand(operands[0], SImode) || >> register_operand(operands[1],SImode)) ..." does not accept mem&&mem. > > The define_expand is used for generating RTL. The RTL expander calls > the define_expand, which checks for MEM&CONST, and then falls through > generating the mem copy insn. > > The define_insn is used for matching RTL. After it has been generated, > we look at the movsi define_insn, and see that MEM&MEM doesn't match, so > you get an error for unrecognized RTL. > > The define_expand must always match the define_insn(s). They are used > in different phases, and they aren't checked against each other when gcc > is built. If there is a mismatch, then you get a run-time error for > unrecognized rtl. > > Jim > > > Great thanks for your explanation. I will look into the internal reason why they must match although that is beyond my work and what I know. Thanks again! -- -Qifei Fan http://freshtime.org
gcc-4.3-20100321 is now available
Snapshot gcc-4.3-20100321 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20100321/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 157610 You'll find: gcc-4.3-20100321.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20100321.tar.bz2 C front end and core compiler gcc-ada-4.3-20100321.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20100321.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20100321.tar.bz2 C++ front end and runtime gcc-java-4.3-20100321.tar.bz2 Java front end and runtime gcc-objc-4.3-20100321.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20100321.tar.bz2The GCC testsuite Diffs from 4.3-20100314 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
