Consider this typical code for method tracing (simplified for illustration):
type
IMethodTracer = interface
end;
TMethodTracer = class(TInterfacedObject, IMethodTracer)
private
FName: String;
FResultAddr: Pointer;
FResultType: PTypeInfo;
public
constructor Create(
const AName: String;
const AResultAddr: Pointer = nil;
const AResultType: PTypeInfo = nil);
destructor Destroy; override;
end;
constructor TMethodTracer.Create(
const AName: String;
const AResultAddr: Pointer;
const AResultType: PTypeInfo);
begin
inherited Create();
FName := AName;
FResultAddr := AResultAddr;
FResultType := AResultType;
Writeln('Entering ' + FName);
end;
destructor TMethodTracer.Destroy;
var
lSuffix: String;
lResVal: TValue;
begin
lSuffix := '';
if FResultAddr <> nil then
begin
//there's probably a more straight-forward to doing this, without involving TValue:
TValue.Make(FResultAddr, FResultType, lResVal);
lSuffix := ' - Result = ' + lResVal.AsString;
end;
Writeln('Leaving ' + FName + lSuffix);
inherited Destroy;
end;
function TraceMethod(
const AName: String;
const AResultAddr: Pointer;
const AResultType: PTypeInfo): IMethodTracer;
begin
Result := TMethodTracer.Create(AName, AResultAddr, AResultType);
end;
//////
function F1: String;
begin
TraceMethod('F1', @Result, TypeInfo(String));
Writeln('Doing some stuff...');
Result := 'Booyah!';
end;
F1();
This is working as intended. The output is:
Entering F1
Doing some stuff...
Leaving F1 - Result = Booyah!
I am now looking for a way to minimize the number of required parameters for the call to TraceMethod(), ideally allowing me to skip the Result-related arguments altogether. I have no experience with assembler or stack layout myself but If I am not mistaken, judging by the "magic" I have seen other people do, at least the memory address of the implied magic Result-variable should be obtainable somehow, shouldn't it? And possibly one can work from there to get at its type info, too?
Of course, if it were possible to even determine the name of the "surrounding" function itself that would eliminate the need for passing arguments to TraceMethod entirely...
I am using Delphi XE2, so all recently introduced language/framework features can be used.
And before anyone mentions it: My actual code already uses CodeSite.EnterMethod/ExitMethod instead of Writeln-calls. I am also aware that this simplified example cannot handle complex types and performs no error handling whatsoever.
Your best bet is truly to just pass in @Result. If you don't, then there's no guarantee that Result even has an address. Functions returning simple types like Integer and Boolean put the result in the EAX register. If there's no reason for the result to have an address, then the compiler won't allocate any memory for it. Using the expression @Result forces the compiler to give it an address.
Merely knowing the address won't get you the return type, though. There might be a way to discover it with RTTI. It would involve three steps:
Extract the class name from the method name. Then you can get the RTTI for that type. This would require the method name to include an unambiguous name for the class (including unit name).
Using the list of methods from that type, find the RTTI for the method. This will be complicated by the fact that the name doesn't necessarily uniquely identify a method. Overloads will all show the same name. (Rruz showed how to deal with RTTI of overloaded methods in the context of the Invoke method.) Also, the method name you get from the debug info won't necessarily match the RTTI name.
Instead of trying to match the name, you could instead loop over all the class's methods, searching for the one whose CodeAddress property matches the address of the caller. Determining how to get the address of the start of the caller (instead of the return address) is proving more difficult to find than I expected, though.
Get the method's return type and use the Handle property to finally get the PTypeInfo value you want.