This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Add support for the Win32 hook prologue (try 3)
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