Re: calling convention stdcalll and cdecl call
* Liviu:
"Alf P. Steinbach" <alfps@start.no> wrote in message
news:SOOdnZ2_8uUQwRjVnZ2dnUVZ_orinZ2d@posted.comnet...
* Liviu:
"Alf P. Steinbach" <alfps@start.no> wrote
* Liviu:
"Alf P. Steinbach" <alfps@start.no> wrote
* Liviu:
But, once you add a requirement that EXX must be preserved/passed
through for some [existing] "stdcall" calls, and recompile client
code using instrument_target to use the new convention, it will
badly fail in those cases.
Yes, it would be stupid, idiotic, braindead, etc. ad nauseam, to
introduce a solution that Does Not Work, imposing new requirements
on existing code.
Right. The instrument_target code, which is language and compiler
neutral, would break because of a change in the semantics of stdcall.
Are you saying the instrument_target code uses stdcall variadic
routines, /before/ support for that exists in the language
implementation?
I am saying that the given instrument_target code supports stdcall
routines, period. Your need to introduce additional qualifiers such as
"/before/ support for [variadic]" makes it only more obvious that what
you are talking about is _not_ stdcall.
Or are you saying the instrumented code uses such routines, /before/
support for that exists in the language implementation?
"/before/" or not is meaningless here. The given code is generic, and
works for any stdcall or cdecl functions, present or future.
You've demonstrated that your code does not work generically for all stdcall
functions, as I understand the term -- because it mangles register values
willy-nilly. ;-)
Anyway, I listed a few ways you could have implemented stdcall variadic routines
so they would work also with your willy-nilly register-modifying trampoline.
As mentioned a great many times already, your ability to invent ways of not
solving a trivial problem doesn't mean the trivial problem can't be solved. In
fact trivial problems are trivial to solve. For the rest of us, I mean.
Note that said change (reserving the EXX register) would not affect
in any way the binary code of instrument_target itself (as could be
present in a .lib or .dll), yet it would break unsuspecting client
code trying to use instrument_target like it always did before such a
"stdcall" redefinition.
Why the heck would you reserve the EXX (any E...) register in general?
Umm... That's straight from your "for example in a register" answer to
the question of how variadic functions would receive the number of
actual arguments. Seems quite obvious that you cannot use a register
unless you somehow reserve it, so that related code knows that it's off
limits to them.
If you choose to use a register for passing the size info to variadic routines,
all that's needed is to document that for this language implementation, a
stdcall variadic routine uses this register, say, ESI; you don't need to reserve
the register in general.
Then, for your trampoline code, it's up to users whether they then decide to
pass it a variadic stdcall routine to call. Given the fact that you're actively
designing it not to be able to handle that, I as a user would simply not use it
for such new stdcall variadic routines. If I were already using it for something
else, it would still work for that, assuming it did work.
But if that's too fine or practical a point for you, by all means, as mentioned,
assume that the size info is passed by pushing it on stack, as in my working
example code at the start of this subthread.
And if by "in general" you mean that the "new stdcall" would have
different register usage specs vs. "stdcall" then, duh.
The stdcall convention has a small and simple set of requirements: for caller,
push right to left, for callee, adjust stack pointer back, and, the only
documentation I've found about register usage[1], preserve all other registers
except eax, ecx and edx. I see below that you provide another MS reference that
says preserve only specific four registers. Well, be conservative.
If a routine complies with that, then as far as the documention I've found says,
it's stdcall.
That's exactly
what would make the "new stdcall" not binary compatible with stdcall.
It is possible but only barely possible that you think that two source code
identical routines compiled as __stdcall with different compilers or compiler
option sets must be binary compatible.
That's not the case with g++ and msvc, which are the main ones I use, and you're
into fantasy-land if you maintain that what they're producing isn't stdcall.
Please repeat some 580 times or so: it's impossible to break binary
compatibility with code that does not yet exist.
You either have a language implementation that supports stdcall variadic
routines, in which case you're not changing anything and not breaking binary
compatibility.
Or you have a language implementation that does not yet support stdcall variadic
routines, and hence you have no such routines and no calls to such routines, and
so can't break binary compatibility with the non-existing calls to the
non-existing routines.
I was not (and the given example was not) referring to any particular
routine. It was about an arbitrary stdcall, which covers any function
present or future which conforms to the stdcall convention.
That's not a meaningful statement. What is "arbitrary stdcall" anyway?
A call to a stdcall function not known at compile time, and about which
no additional assumptions are made except that it's stdcall.
You know, that problem pops up all the time in practical programming, every day.
Yep, don't know the function at compile time, check; and yep, don't know
anything more than that it's stcall, check; and yep, must call it, check.
Anyway, the proper way to deal with "no assumptions" is to make no assumptions.
Your code on the contrary assumed that anything that wasn't documented as being
of importance to a stdcall function would be up for grabs to destroy. The state
of the documentation being what it is, with errors and omissions and
inconsistencies galore, well that's a pretty bad approach. You're not talking
about the old MS COM-interceptor, are you?
For all I care, the client code could ask the user to type in the name
and signature of an arbitrary stdcall function exported from msvcrt.dll,
push arguments consistent with the signature onto the stack, fetch the
function address at runtime from msvcrt.dll and copy it into EAX, then
call instrument_target - and expect the call to eventually land into the
given function and work correctly. That would work regardless of whether
the function in question existed or not when instrument_target was
written. All that matters is that the function is stdcall.
a practical solution is to call stdcall something else in this
contex, e.g. __stdcallv.
OK, then I'd call this case closed.
You're confused again. But if you're happy, so be it.
Not at all. Call it __stdcallv, and any objections about compatibility
would become moot.
Ouch. As mentioned quite a few times, I don't think it's a good idea to
implement this. But I think that for what I believe to be valid reasons, given
earlier, not invalid techno-babble-philosophical objections.
So perhaps I should not have mentioned this about keywords.
But note that keywords, in e.g. Visual C++ or some Pascal version, are not the
same as calling conventions. They /denote/ calling conventions.
So perfectly legit code according to the existing specs
I wonder where the specs are that says which registers a forwarder
can and cannot freely change for stdcall, do you have a reference?
You'll find some at
http://msdn.microsoft.com/en-us/library/aa295770.aspx.
Perhaps Internet Explorer shows more there than my Firefox, but at
least in Firefox there's nothing there about general register usage.
|| Registers:
|| this (thiscall only) ECX
|| not used EDX
For subsets of stdcall families (such as the Win32 API) there are
more rules, of course.
Just out of curiousity, do you have any reference
http://support.microsoft.com/kb/232587/en-us
Hm, thanks, says nearly but not exactly the same as the one I found[1]. Neither
article says anything about which registers a trampoline can trample on on the
way in. They only say what registers must be preserved on the way out, and
contradict each other on that; however, preserving all must be safe.
The prudent thing to do is then to not trample on any registers on the way in,
nor on the way out.
That's the same as the prudent thing to do in the absence of that documentation.
Point is however that anything which is not declared as "used"
or "reserved" is considered to be available for use.
Do you have a reference for that?
Google for "what's not occupied is available" ;-)
I think you have that backwards for a trampoline function.
It needs to do the opposite, to consider anything it isn't expressly allowed to
trample on, off-limits.
if you want the trampoline to also work with new stdcall variadic
I just want the code to keep working with stdcall functions. Yours "new
stdcall variadic" are none such.
That quote is not a quote of me.
The variadic functions are not new, it's very very old stuff (not from the
Egyptian faraohs, but nearly).
A stdcall variadic function is just that, a varidia function fulfilling all
requirements of stdcall convention. If in your view that means not being passed
information via a register, then why not pass it on the stack. My working
example code at the start of this subthread did exactly that -- although I
disagree that it's necessary to go that length to support dirty bad trampoline
code, that disagreement is a very very minor practical point of implementation,
trivial (as this all is, by the way).
the best solution would be to fix the bad trampoline code.
What's bad about it?
You've yet to show that your code is correct.
Do you really think it's not, or are you just trol^H^H^H^Hkidding.
I think that trampoline code is not good, because you've stated that it can
trample on any registers (except critical ones like esp) on the way in.
That's not a good thing to do.
It wouldn't be a good thing to do even if some stdcall documentation expressly
allowed it to, because it can cause it to fail where otherwise it wouldn't.
Second, consider, if on the way in it changes ESI or EDI, or according to [1]
/any/ register except eax, ecx and edx, then it needs to save those register
values somewhere, and make a CALL, not a JMP, in order to be able to restore
those values on the way out, because that preservation vis-a-vis calling code
/is/ a requirement of stdcall. It won't do to just push them on the stack prior
to invocation of target. They must be saved somewhere else, for thread safety in
thread local storage. Then you're introducing extreme inefficiency, relative to
this functionality (sitting in the middle of a host of call chains), and also
problems with dynamically loaded DLLs. So in order to do this ungood stuff,
trampling on all registers that could be used to pass arguments size, you have
to do a lot of complicated stuff you'd otherwise not need to do, plus
introducing (relatively speaking) extreme inefficiency, plus, I think, making
your trampoline unusable in certain scenarios relating to DLLs.
Now if that trampling trampoline doesn't qualify as a purely academic objection,
far out of any practical consideration, then I don't know what is.
Anyways, good code in general has a property called *robustness*.
It doesn't avail itself of pecularities of a given small context of
usage, but is designed to work in general, assuming the least instead
of the most about its environment.
Oh, the irony. It is _you_ who in effect is saying "gee, here is a
register I am going to steal for calling variadic functions with my new
convention, I bet no one knew that register existed, so I'll just assume
no existing code would break if I misrepresent my new convention as
stdcall".
Again, it's impossible to break existing code.
All that can happen in the worst case is that some existing very badly designed
code (see right above for details about why it necessarily must be specially
tailored to be problematic, unless created by moron) can't be used to handle the
new stdcall variadic functions, which is no problem.
In best case, which except for academic objection (see above) is expected, there
are not even such restriction on usage of the new functions, and in guaranteed
case, trading a little efficiency (e.g. push instead of register), there are not
even any potential problems.
Cheers, & hth.,
- Alf
Notes:
[1] <url: http://msdn.microsoft.com/en-us/library/cc267758.aspx>
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?