Add support for the Win32 hook prologue (try 3)

Pedro Alves pedro@codesourcery.com
Fri Sep 11 18:23:00 GMT 2009


On Friday 11 September 2009 18:41:35, Kai Tietz wrote:

> Well, first. Why should be the content of the part before function
> entry of any interest. 

I did start with a question.  Let me recap:
"I was picturing an app refusing to hotpatch if it sees something
else there, but I wouldn't know if that's a problem in practice."

> Secondly, the align statement in code section 
> always fills with nops. 

nops, but not 1-byte _NOP_.

        .text
        .align 1
        nop
        nop
        nop
        nop
        nop
        .align 4
foo_function:
        ret

Disassembly of section .text:

00000000 <foo_function-0x8>:
   0:   90                      nop
   1:   90                      nop
   2:   90                      nop
   3:   90                      nop
   4:   90                      nop
   5:   8d 76 00                lea    0x0(%esi),%esi

00000008 <foo_function>:
   8:   c3                      ret



Googling hits this: <http://www.openrce.org/articles/full_view/22>, which
mentions something about ">= 5 bytes, padded with 0xCC".  I didn't take
the time to read the whole document.


> And secondly, why should do this linker 
> better?

You mean thirdly.  :-)  

> If done outside of gcc, it needs to be done in assembler seeing a
> function label

Eww.

> (or a specific pseudo-code, which btw needs to be 
> emitted by gcc, too). 

Of course.

> The linker is the absolute wrong assumption 
> here. The linker sees already compiled and pre-relocated objects. You
> would need to re-generate object (as gas does it in write_object) and
> have a glass-ball to see which pre-relocated label needs to be
> adjusted. The linker approach  makes to me less sense.

I said "assembler or linker".  As in, e.g., with a new assembly
pseudo-op ".add_me_patching_nops_please", which would add the least
amount of needed NOPs and whatever else is allowed in a patching pad
glued right to the bottom of the function entry, while still respecting
function entry alignment.  I do wonder why MSFT does it in the
linker, though.

-- 
Pedro Alves



More information about the Gcc-patches mailing list