Mapping memory address of unknown method

[P_A__Jimenez]

Hi.

I have been quite satisfied with the profiling results generated by Intel Amplifier, but, unfortunately, I also make use of a programming language that the tool is not made for: Delphi.

I was trying some profiling tools targeted for Delphi, but none of them gave satisfactory results (no need to name them). I then decided to give Intel Amplifier a try with a Delphi program that was taking too long to save a project, but all I got back in the callstack was a memory address per method. I have the map file generated by Delphi in which I can look up which memory address belongs to which unit, method and line number, but the memory addresses reported by Intel Amplifier did not match. Adding or removing the base address 0x00401000 was of no use either. After some trial and error, I managed to find that I must add about 0x000CB160 to the memory address reported by Intel Amplifier in order to, almost, get to the proper line number reported in the map file. This way I managed to find the bottleneck and solve the issue, which is great and all, but I am still wondering: how do I know the proper value to add to the memory addresses reported by Intel Amplifier, so I can look them up in the map file? Is there any tool I can use for this purpose? Is it a known constant? Is it, perhaps, a bug in Intel Amplifier?

Thanks.

[Peter_W_Intel]

I wonder that Delphi is not supported compiler, please see release notes.

[P_A__Jimenez]

Peter Wang (Intel) wrote:

I wonder that Delphi is not supported compiler, please see release notes.

I know Delphi is not supported, and that is why I have to manually look up the memory addressed reported by Intel Amplifier into the map file Delphi produces. My question is related to the memory addresses themselves, as they seem to be either wrong, or there is a constant value that I am missing (around 0xCB160) that then I would like to know where it comes from and how to retrieve it properly. Just for the record, I am not asking for Delphi support in Intel Amplifier (even if it would make things easier for me). As a bonus question: would Intel Amplifier show full stack information if, somehow, I got a matching pdb file next to the Delphi executable, or does it retrieve the information from somewhere else? Thanks.

[SergeyKostrov]

>>...I must add about 0x000CB160 to the memory address reported by Intel Amplifier in order to, almost, get to the proper >>line number reported in the map file... 0x000CB160 looks like a random number and it doesn't look like a constant. For a constant I would expect a number that is a power of 2, or something more logical. Did you try to look at a PE header of a Delphi executable?

[P_A__Jimenez]

Sergey Kostrov wrote:

>>...I must add about 0x000CB160 to the memory address reported by Intel Amplifier in order to, almost, get to the proper
>>line number reported in the map file...

0x000CB160 looks like a random number and it doesn't look like a constant. For a constant I would expect a number that is a power of 2, or something more logical. Did you try to look at a PE header of a Delphi executable?

Delphi uses 0x00401000 by default as the start address for the code section, and that's the one used in the program. When debugging a C++ DLL used by the Delphi executable, the memory addresses reported in the executable (which Visual Studio does not know how to map to a method, even less a line), are perfectly matched to a file and line using the map file generated by Delphi. It's only the memory addresses reported by Intel Amplifier the ones that do not match at all because they are offset by a very strange value (which seems to be constant, at least for the executable in question). Checking the PE header shows nothing alike that 'constant'. I'm tempted to believe that it's indeed a bug in Intel Amplifier. A minor bug, but, still, a bug.

[SergeyKostrov]

>>...Checking the PE header shows nothing alike that 'constant'. I'm tempted to believe that it's indeed a bug in Intel Amplifier. >>A minor bug, but, still, a bug. How did you debug a Delphi executable with a VS? Does the Delphi create a Microsoft compatible Pdb-file?

[P_A__Jimenez]

Sergey Kostrov wrote:

>>...Checking the PE header shows nothing alike that 'constant'. I'm tempted to believe that it's indeed a bug in Intel Amplifier.
>>A minor bug, but, still, a bug.

How did you debug a Delphi executable with a VS? Does the Delphi create a Microsoft compatible Pdb-file?

What I mean is that I was debugging a C++ COM DLL that the Delphi executable makes use of. I can see the memory addresses from the executable in the call stack, and I can map them properly to a file and line using the map file. Same thing if Visual Studio catches an exception thrown in the Delphi executable: I can map the memory address in the call stack to the proper file and line. It's only Intel Amplifier that shows improper addresses (offset by some sort of constant value, as I mentioned in the original post).

[P_A__Jimenez]

I just tried to profile another Delphi executable that makes use of the C++ COM DLL with Intel Amplifier, and the results are slightly different. According to Intel Amplifier, a COM method in the DLL is called from memory address 0x8645c3 in the Delphi application, but, according to the map file, the memory address where it is called from is located between 0x930951 and 0x93095F. That means an average of 0xCC395 that must be added to what Intel Amplifier reports in order to find the proper place in the map file. It's still rather close to the 0xCB160 I found with the other program, yet far from making any sense.

[P_A__Jimenez]

Hi.

Would you kindly inform me if any attempt has been made to check how Intel Amplifier determines the memory address in the call stack for frames it does not have a pdb to look into? I still seriously think it's a bug in Intel Amplifier (fortunately not one that causes it to crash, but, still, a bug).

Thanks.

[Bernard]

>>>Would you kindly inform me if any attempt has been made to check how Intel Amplifier determines the memory address in the call stack>>>

Probabaly by tracking memory address range of instruction pointer.

[P_A__Jimenez]

I decided to give the profiling another go, and I noticed that Amplifier now shows the unknown addresses in a different format (or maybe it's the same format and I just do not remember them looking like that before). Better than that, now the addresses point to the right place, without any strange offsets (other than the familiar 0x00401000). They even include the offset to the place the call to the previous function on the stack occurs: program.exe!func@0x818030+0x2d :)

Thanks for the fix. It's highly appreciated.

[Bernard]

It seems that maybe lack of pdb file was a culprit of improper function address recognition.

[Vitaly_S_Intel]

binksoftware, thanks for your feedback!

FYI, in case of absence of debug information function range is properly calculated using static binary analysis starting from Update 11. More details may be found here.

[Bernard]

Hi Vitaliy 

By writing "static binary analysis" do you mean performing disassembling of the function(s) and looking for the prolog and epilog and thus calculating the address space(range) of the function?

Thanks in advance

[Vitaly_S_Intel]

Hi Ilyapolak!

It is disassembling and control flow analysis.

[Bernard]

Thanks