![]() |
|
|
|
#1
|
|||
|
|||
|
it works, indeed. i used a similar method too, although i didn't like it much, but there is no clean solution to do so
(at least, none that i know of)
|
|
#2
|
|||
|
|||
|
This will not necessarily work because function code is NOT contingues in memory. Function code can be splitted in several code segments.
The only thing do get the real size is via debug symbols. xMaster |
|
#3
|
|||
|
|||
|
Even if the functions are in the same segment, the result is probably always a multiple of 16, because the functions are usually aligned to paragraph borders (historical reasons) and the room is filled with nops or int 3-s. So in the best case you get the size of your function rounded up to be dividable by 16.
Last edited by mihaliczaj; 09-08-2004 at 20:19. |
|
#4
|
|||
|
|||
|
No I would say it is aligned on 16 byte (or whatever) because of cpu/memory caching reasons.
This is not neccessaryly 16 Byte. CPU data cacheline size on current modern cpu's is 64 Byte. xmaster |
|
#5
|
|||
|
|||
|
very helpfull... thanks
|
|
#6
|
|||
|
|||
|
Having the target on a 16 byte boundry is very important for performance reasons on a non-P4 (or even a P4/P4 Xeon if the target is not in the uOP cache). The reason is the IFetch buffers are loaded directly from tag lines, and thus, if they are not aligned, you are paying for fluff (i.e. bytes will be loaded that are never used).
As xMaster said, in an ideal world, 64 bytes would be even better, but could you imagine 63 bytes-o-NOPs between single ret functions? Only Microsoft... (I kid, actually their compilers arent that bad). |
![]() |
| Thread Tools | |
| Display Modes | |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| how to calculate RVA from file offset | Shub-Nigurrath | General Discussion | 9 | 09-22-2009 12:33 |