I have an application consisting of mixed C and x86 assembly code. For complex reasons, the assembly code wants to know if a (purported program counter) value is an address in the area in which the object code for the C code exists. This application has worked very well in the past, including this oddball check.
All I actually need are “bookends” on the C code area whose addresses I trust.
This of course assumes that the compiled C code is deposited in the load image relatively densely.
I currently get my bookends by defining dummy functions LowestAddress(){} and HighestAddress(){} and placing them respectively first and last in the file containing the code. The assembly code simply compares a value of interest to the the addresses of these functions to determine if that value is in the C code range. Oops, this makes a second assumption, that functions are ordered in memory in source file text order, which used to apparantly be true with much older versions of Visual Studio.
Alas, no longer, certainly not with VS2010 compiling with link-time code generation. (I don’t know what other [non]optimizations settings do.) On inspection with VS2010, my LowestAddress function is clearly in the middle of the object code for a bunch of other C functions.
How can I (re)implement these bookends? Some kind of segment control? The options available for build in VS 2010 don’t seem to offer anything useful. (I understand that a really smart compiler might actually re-arrange the code to minimize cache line conflicts based on a call graph. Is MS actually that smart?). I don’t really insist on ordering all the functions in this region by text order; I just need the upper and lower bounds of the region.
[I’m going to try turning off link-time code generation, which is the only place that a [global] call graph could be constructed, and see what effect that has.]
You can specify the order of how functions are placed in a image by using the /ORDER compiler parameter.