Quoting Stefan Dösinger :
Here's some code attached that actually works, but is far from perfect.
The 'msvc_prologue' attribute is limited to 32 bit. None of the applications
that try to place hooks are ported to Win64 yet, so it is impossible to tell
what they'll need. Besides, maybe I am luck
> For my purposes it is not really suitable, because we have to make sure that
> the push %ebp and mov %esp, %ebp are there, no matter what the compiler
> arguments are(-fomit-frame-pointer). So just adding the mov %edi, %edi isn't
> enough, and while I'm at it I can add the .s to the insns anyway.
> Have you thought about making .s an assembler command-line flag, so
> that
> this flag could be passed automatically by the compiler under mingw?
Yes.
For my purposes it is not really suitable, because we have to make sure that
the push %ebp and mov %esp, %ebp are there, no matter what the compi
> movl.s %edi, %edi
> pushl %ebp
> movl.s %esp, %ebp
Have you thought about making .s an assembler command-line flag, so that
this flag could be passed automatically by the compiler under mingw?
Paolo
Here's some code attached that actually works, but is far from perfect.
The 'msvc_prologue' attribute is limited to 32 bit. None of the applications
that try to place hooks are ported to Win64 yet, so it is impossible to tell
what they'll need. Besides, maybe I am lucky that when they appear I can
> If ebp needs to be saved because it contains a user variable, it is
> better
> not to pop it in the prologue - pop it in the epilogue instead, and you
> don't
> need to have another save/restore.
Sounds reasonable. Is there any flag I can set to make the epilogue pop ebp?
> This can be done wit
Quoting Stefan Dösinger :
If the frame pointer is not needed:
mov.s %edi, %edi
push %ebp
mov.s %esp, %ebp
pop %ebp
; Continue normally here. I think that case can't be improved too much,
since the msvc_prolog stuff modifies the base pointer.
If ebp needs to be saved because it contains a use
> You don't need to force the frame pointer on, it is sufficient to say
> that
> ebp needs restoring at the end of the function no matter if it looks
> otherwise
> used or not - and you have to take the frame size impact of the saved
> ebp into
> account.
How does this fit together with the stack
Quoting Stefan Dösinger :
I talked to Alexandre again, and his main concern wasn't so much the global
flag, but that the existance of the push %ebp; mov %esp, %ebp was still up
to the feelings of the compiler and the moon phase.
So what he wants is something like a msvc_prolog attribute that ma
> >> But since you have to have a new gas anyway, wouldn't it be simpler
> to
> >> have
> >> a new option for gas to instruct it to choose the opcodes that are
> >> expected
> >> by the win32 applications?
> > This was my first idea, but Alexandre Julliard(the Wine maintainer)
> disliked
> > it and
Quoting Stefan Dösinger :
But since you have to have a new gas anyway, wouldn't it be simpler to
have
a new option for gas to instruct it to choose the opcodes that are
expected
by the win32 applications?
This was my first idea, but Alexandre Julliard(the Wine maintainer) disliked
it and prefer
Quoting Stefan Dösinger :
But since you have to have a new gas anyway, wouldn't it be simpler to
have
a new option for gas to instruct it to choose the opcodes that are
expected
by the win32 applications?
This was my first idea, but Alexandre Julliard(the Wine maintainer) disliked
it and prefer
>> But since you have to have a new gas anyway, wouldn't it be simpler to
>> have
>> a new option for gas to instruct it to choose the opcodes that are
>> expected
>> by the win32 applications?
> This was my first idea, but Alexandre Julliard(the Wine maintainer) disliked
> it and prefered a funct
> An example of an unspec_volatile instruction pattern in
> config/i386/i386.md
> is "cld".
I ran across that, your hints should give me some information to chew on for
the next hours. Currently I am compiling with this code to see what happens:
(define_insn "movnop"
[(unspec_volatile [(const_int
Quoting Stefan Dösinger :
Thanks for the hint - I'll see what I can find. Do you have any hints for
good examples in the existing code?
An example of an unspec_volatile instruction pattern in config/i386/i386.md
is "cld". Note that by giving the pattern a name which is not prefixed with
'*',
> You can make a new instruction pattern with an UNSPEC_VOLATILE pattern.
> For a quick prototype you could also use an assembler prologue,
> although
> if you need not experiment with different insn sequences, this will
> likely
> be more work in the long run if/when assembler prologues are eventu
The attached file gcc.diff contains a kinda helpless attempt to generate
this instruction. My first problem is that any optimization optimizes it
away because it is a NOP. Is there any way to prevent the optimizer from
removing it?
You can make a new instruction pattern with an UNSPEC_VOLATILE p
> -Original Message-
> From: H.J. Lu [mailto:hjl.to...@gmail.com]
Nice to see a familiar face, or better, mail address :-)
> You need to check assembler feature with autconf before using them.
> See HAVE_AS_IX86_SAHF as example.
Thanks!
Does that look ok? It seems to detect the support
On Wed, Jan 7, 2009 at 10:05 AM, Stefan Dösinger wrote:
>
> I talked to the binutils maintainers and they helped me by adding a new
> instruction suffix .s:
> movl%esp, %ebp => 89 e5
> movl.s %esp, %ebp => eb ec
>
> Now I need gcc to set this suffix, but here I am pretty lost. I haven't
Hello,
I am working on the Wine project(www.winehq.org), which (obviously) uses gcc
to compile its own code. There are some Windows applications like
Steam(www.steampowered.com) and others which try to hook Win32 API functions
by patching the first 5 bytes of the Windows API functions exported by
20 matches
Mail list logo
