David Brennan replied:
> Thanks Max - I thought I could rely on you to provide a useful reply!
Well sucks. Ain't that flattering 8-)
> Will the VMT only contain information on virtual and dynamic
> methods? That is, if a class has 3 virtual methods and 5 normal
> (non dynamic/virtual) methods then surely only the 3 virtual
> methods are built into the VMT?
Correct. The VMT is called the Virtual Method Table for a good reason you
know. Its basically a bunch of pointers to procedures that are the
implementation for a virtual method for a particular class. Each class has
its own VMT so that each class can have its own implementation of the
virtual methods.
The dynamic methods on thew other hand only have an entry in the VMT for
class for which they are defined. When a dynamic methods is dispatched the
code in System walks a classes parent hierarchy searching each VMT for the
dynamic method that matches the one being dispatched. This slower to
dispatch, but uses less RAM than a standard virtual method which much be
duplicated in each classes VMT.
Static methods calls are resolved at link (and in certain cases load) time
and are just 32 bit offsets into the code somewhere. There is no other
information stored about them unless your prepared to do some serious
hacking into the PE executable file structure and unravel all the load
time fixups stuff.
> On a slightly different tack, when the CPU debug window is open
> listing the assembler code it contains labels every few lines
> (such as function names, source code line numbers). Presumably
> these are inserted for our benefit by the CPU window and they
> aren't actually present in the EXE file?
All the magic debugging information is tucked away in the DCU files, and
the IDE debugger extracts it all and figures out what you are looking at
from the memory location. If you want to get a feel for some of what is
stored do a link with a detail map files being generated, and you'll see
that their is a heap of information about the line numbers and offsets
into the code. Add to that information about local variable locations on
the stack, call parameters and type, global variables, and you have the
information stored in a DCU.
As an aside we have used a combination of detailed linker information and
an exception time stack tracer to have a way for our users to send us
errors and for us to be able to turn these back into a actual stack trace.
very useful in determining where things have gone wrong on a client
machine.
You also get the same information in the executable if you turn on the
TD32 debugging information option in the linker. This is useful if you are
using third party debuggers, profilers and testing tools, or you want to
use a tool to convert from TD32 to SYM and have DrWatson doing stuff for
you when you get a death.
Cheers, Max.
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
To UnSub, send email to: [EMAIL PROTECTED]
with body of "unsubscribe delphi"
