Standard Prologue/Epilogue

[Biterider]

Hi
If we want to change something when a procedure is called, we have to redefine the standard prologue or epilogue. Now, if I want to add something before or after the standard prologue/epilogue, is there a way to call the standard prologue/epilogue generation from within their modified versions?
 

Code: [Select]

NewPrologue macro ProcName, Flags, ParamBytes, LocalBytes, RegList, UserParams
    Call StdPrologue, ProcName, Flags, ParamBytes, LocalBytes, RegList, UserParams
    DoMyStuff
    exitm <0>
endm
Biterider

[johnsa]

I don't believe so. If the prologue is set to default then the code generates the operations directly as opposed to substituting in the macro.
We could look at allowing evaluation of the default prologue if you inserted option prologue:default into your actual macro.

[mabdelouahab]

johnsa
If we can figure out the name of the default  Prologue macro, Something like @Line,@FileName,@CurSeg,... , for example @DefaultPrologueMacro
So that we can use it as follows

StdPrologue equ @DefaultPrologueMacro
NewPrologue macro ProcName, Flags, ParamBytes, LocalBytes, RegList, UserParams
    DoMyStuff
    exitm <StdPrologue(ProcName, Flags, ParamBytes, LocalBytes, RegList, UserParams)>
endm
OPTION PROLOGUE:NewPrologue

Answer with johnsa

[jj2007]

Have you thought of doing it the other way round?

PrologueDef macro ProcName, Flags, ParamBytes, LocalBytes, RegList, UserParams
   if defined @UserPrologue
        @UserPrologue ProcName, Flags, ParamBytes, LocalBytes, RegList, UserParams
   endif
...

[Biterider]

Hi
Yes, good point.
In this case you will need 4 callbacks or user-macros. Before and after the user defined code and for the prologue and the epilogue.
Arguments for this callbacks/macros can be a bit tricky, since you don't know what you want to pass to them. This needs a bit of elaboration.

Using the first approach, you will only need 2 callbacks/macros to the default prologue and epilogue.

Biterider

[johnsa]

As I mentioned, there is no "default" macro. If the default mode is enabled, the assembler directly generates the prologue.
The option from my side would be a sort-of, "pre"-prologue macro.
I'm curious what you'd be looking to do with this, perhaps there is another solution that doesn't involve messing with the prologue at all ?

[Biterider]

Hello John
Things were much easier in the 32-bit world. Because the prologue and epilogue code is much simpler, you could handle it.
In 64-bit world, the prologue and epilogue have become much more complicated and additionally depend on many settings.

This feature request targets the following usage:

• OOP / COM redirection after the default prologue
• Detecting a buffer overflow by inserting a security cookie value after the default prologue (like /GS switch) and finally checking and removing it before the default epilogue.
• Performance measurement inserting code before the default prologue and after the default epilogue.

That means, if we want to follow the suggested path, that we need 4 macros: a pre- and a post- prologue and epilogue macro.

Biterider

[johnsa]

The easiest to implement solution would be:

Currently we have these options:

option prologue:none
option prologue:default
option prologue:usermacro

If we add:

option prologue:usermacro,default

That would add the usermacro code before generating the default.. and the same in reverse for epilogue.

If you're ok with that I will add it to our list.

[mabdelouahab]

For me, that's good, because I'm looking for the same thing, but for Biterider I don't know.

[Biterider]

Hi
I'm risking to be the bad guy, but the first 2 points

• OOP / COM redirection after the default prologue
• Detecting a buffer overflow by inserting a security cookie value after the default prologue

can not be implemented if

option prologue:usermacro,default
That would add the usermacro code before generating the default

Imho, we have to look how to trigger the default code generation from within the usermacro.

BTW, the security cookie should be an option for the default prologue/epilogue like it is for some compilers.

Biterider

[jj2007]

Hi biterider, bad guy ;)

What stops you from simply writing a prologue macro that has all the features you need? You don't need any additional intervention from the assembler, even bad ol' ML can do that...

[mabdelouahab]

jj2007, maybe he needs some modifications to the input, that he see as necessary.
For example

NewPrologue macro ProcName, Flags, ParamBytes, LocalBytes, RegList, UserParams
    DoMyStuff
    exitm <StdPrologue(ProcName, modifiedFlags, ParamBytes, modifiedLocalBytes, modifiedRegList, UserParams)>
endm

Sometimes we need things that way.

[aw27]

It took some time to tune UASM to work well with 64-bit SEH. I don't think, but may be wrong, we can design a "default" macro for that. Even Masm does not use since long default prologue/epilogue macros, a few things can't be done proper and cleanly that way.
I know that people that make standalone asm applications is not concerned at all with SEH. But they are not concerned as well with security cookies/canaries.
However, the solution presented by johnsa seems reasonable but in reverse order because I don't see any reason to expect a second epilogue after the epilogue or insert extraneous code before or in the middle of a prologue. These areas are sacred. For special requirements do full prologue/epilogue macros by hand and good luck.
Just my 2 cents.

[Biterider]

Hi
When I read the last post, it occurred to me that I completely forgot about SEH!
For me it makes no sense to have a second epilogue, since nothing is executed after the return instruction from the default epilogue anyway.
Thus, everything could be reduced to a pos-prologue and pre-epilogue, as written preciously.

I think that the timing and performance stuff can also be done with this approach.
A delicate thing is the pos-prologue when you change the stack. This needs more elaboration to be done properly.

Biterider

[johnsa]

Well for post-prologue and pre-epilogue we shouldn't need to touch anything as that would be possible now.
AW is right, he has done some excellent 64bit SEH work and put me through the ringer to make it work properly under different modes and proc styles :)