Profiler for Delphi

[Anders Melander 1639]

6 minutes ago, Attila Kovacs said:

does pdb2yaml gives the same yaml back?

Yes. As far as I can tell.

I have also tried validating the pdb but there aren't really any tools (that I've found) that can analyze a pdb for validity.

 

I think the problem is more about what values I need to provide in the pdb (for example I don't have type information or mangled names so I can't write those) and what the meaning of the values are. One of the things I've struggled with are address values. Are they absolute or relative and if relative, then relative to what.

I currently assume the following:

• Segment: Absolute
• Module (Unit): Relative to Segment
• Line: Relative to Module
• Symbol (method/function): Relative to Module

But I have tried just about all different combinations. Since VTune doesn't provide any feedback on the address resolution (other than crash/no crash) I have just to throw everything at the wall to see what sticks. Pretty frustrating. I even tried attaching to the VTune backend with the debugger to examine what it did but I quickly gave up on that as it (not surprising) is massively multi threaded and simply too complex for that approach.

[Attila Kovacs 617]

2 minutes ago, Anders Melander said:

then relative to what

to the base address

I can check it. Which section should I look in the map?

[Attila Kovacs 617]

0001:00401000 0190D0A0H .text                   CODE

 

why is it .text? anyway

 

0001:0151D808       unit.frmxyz.BtnNewClick 

 

0151D808 + 00401000 is the actual address

 

(400000 is the image base and 1000 is the section alignment)

Edited March 16, 2021 by Attila Kovacs

[Anders Melander 1639]

1 minute ago, Attila Kovacs said:

to the base address

I can check it. Which section should I look in the map?

I'm not sure what saying - or asking...

 

I know what the values in the map file means (they're all absolute [*]). It's the values that I need to put in the yaml/pdb that I'm unsure about.

 

[*] Of course all addresses are relative in a sense, since it's only after the exe has been mapped into virtual memory that absolute addresses can be known. When I say "relative to the segment" I mean these from the map file:

 Start         Length     Name                   Class
 0001:00401000 0011B0C0H .text                   CODE
 0002:0051D000 00001144H .itext                  ICODE
 0003:0051F000 00003BACH .data                   DATA
 0004:00523000 0000645CH .bss                    BSS
 0005:00000000 00000020H .tls                    TLS
 0006:00400000 00000000H .pdata                  PDATA

 

[Attila Kovacs 617]

Ah I see, well, I tried to convert some pdb's to yaml but after it failed on every pdb's I've found I got upset and forensic wiped it from my ssd 😉

I've no idea how good this yaml converter is but after that I've doubts.

Edited March 16, 2021 by Attila Kovacs

[Anders Melander 1639]

5 minutes ago, Attila Kovacs said:

why is it .text? anyway

Historical reasons probably.

https://softwareengineering.stackexchange.com/questions/171565/why-is-the-code-section-called-a-text-section

https://stackoverflow.com/questions/1282506/where-did-the-text-segment-get-its-name

[Anders Melander 1639]

7 minutes ago, Attila Kovacs said:

ah I see, well, I tried to convert some pdb's to yaml but after it failed on every pdb's I've found I got upset and forensic wiped it from my ssd 😉 

🙂 yeah they need to be fairly recent. Since LLVm only produce they "new" PDB format it doesn't need to support the older formats. I think anything older that 5 years will probably fail.

[Stefan Glienke 1905]

It might be worth asking over on https://community.intel.com/t5/Analyzers/bd-p/analyzers. Maybe someone can give you a pointer into the right direction.

Also did you try the pdb in WinDbg?

Edited March 17, 2021 by Stefan Glienke

[Anders Melander 1639]

19 hours ago, Stefan Glienke said:

It might be worth asking over on https://community.intel.com/t5/Analyzers/bd-p/analyzers.

I've tried that but for some reason I can't get past their community registration. I registered when I downloaded VTune but when I try to post to their forum I get stuck in a registration confirmation loop. Tried with different accounts, different browsers.

 

19 hours ago, Stefan Glienke said:

Also did you try the pdb in WinDbg

No. Never used WinDbg.

If someone else want to have a go at it I'll be happy to supply a zip with source, exe and pdb.

 

I verified the exe/pdb with symchk from Debugging Tools for Windows and it passed with no problems:

D:\Projects\map2pdb\Bin\Win32\Debug>"D:\Development\Debugging Tools for Windows (x86)\symchk.exe" -v map2yaml.exe -s D:\Projects\map2pdb\Bin\Win32\Debug /pf
[SYMCHK] Searching for symbols to D:\Projects\map2pdb\Bin\Win32\Debug\map2yaml.exe in path D:\Projects\map2pdb\Bin\Win32\Debug
DBGHELP: Symbol Search Path: D:\Projects\map2pdb\Bin\Win32\Debug
[SYMCHK] Using search path "D:\Projects\map2pdb\Bin\Win32\Debug"
DBGHELP: No header for D:\Projects\map2pdb\Bin\Win32\Debug\map2yaml.exe.  Searching for image on disk
DBGHELP: D:\Projects\map2pdb\Bin\Win32\Debug\map2yaml.exe - OK
DBGHELP: map2yaml - public symbols & lines
         D:\Projects\map2pdb\Bin\Win32\Debug\map2yaml.pdb
[SYMCHK] MODULE64 Info ----------------------
[SYMCHK] Struct size: 1680 bytes
[SYMCHK] Base: 0x00400000
[SYMCHK] Image size: 6230016 bytes
[SYMCHK] Date: 0x60526592
[SYMCHK] Checksum: 0x00000000
[SYMCHK] NumSyms: 0
[SYMCHK] SymType: SymPDB
[SYMCHK] ModName: map2yaml
[SYMCHK] ImageName: D:\Projects\map2pdb\Bin\Win32\Debug\map2yaml.exe
[SYMCHK] LoadedImage: D:\Projects\map2pdb\Bin\Win32\Debug\map2yaml.exe
[SYMCHK] PDB: "D:\Projects\map2pdb\Bin\Win32\Debug\map2yaml.pdb"
[SYMCHK] CV: RSDS
[SYMCHK] CV DWORD: 0x53445352
[SYMCHK] CV Data:  map2yaml.pdb
[SYMCHK] PDB Sig:  0
[SYMCHK] PDB7 Sig: {CBB17264-89FA-4AED-A2D7-814EE276EF3E}
[SYMCHK] Age: 1
[SYMCHK] PDB Matched:  TRUE
[SYMCHK] DBG Matched:  TRUE
[SYMCHK] Line nubmers: TRUE
[SYMCHK] Global syms:  FALSE
[SYMCHK] Type Info:    FALSE
[SYMCHK] ------------------------------------
SymbolCheckVersion  0x00000002
Result              0x000f0001
DbgFilename
DbgTimeDateStamp    0x60526592
DbgSizeOfImage      0x005f1000
DbgChecksum         0x00000000
PdbFilename         D:\Projects\map2pdb\Bin\Win32\Debug\map2yaml.pdb
PdbSignature        {CBB17264-89FA-4AED-A2D7-814EE276EF3E}
PdbDbiAge           0x00000001
[SYMCHK] [ 0x00000000 - 0x000f0001 ] Checked "D:\Projects\map2pdb\Bin\Win32\Debug\map2yaml.exe"

SYMCHK: FAILED files = 0
SYMCHK: PASSED + IGNORED files = 1

The above just verifies that the exe reference to the pdb is correct and that the pdb is valid and contain line number information. I don't think symchk can validate deeper than that.

I get similar output when I run it on the matrix.exe sample provided with VTune, except that one also has symbol & type information in the pdb.

 

Since I could see that VTune was looking in it's own bin directory for files with the same name (sans type) as the modules in my pdb I tried copying the source files there and rename them to match what it looked for. Apparently it wasn't source files it was looking for because it just read the first 56 bytes of each file and it made no difference in the end. My guess is that it was looking for obj files.

[Anders Melander 1639]

Just now, Anders Melander said:

My guess is that it was looking for obj files.

It was.

This is what happened when I changed the YAML to include the module ObjName property with a reference to the dcu (of course the map file doesn't contain the obj filename so I'm just supplying a dummy filename):

Looks like a bug in VTune.

[Stefan Glienke 1905]

Just a few random thoughts:

Could this be the case? https://community.intel.com/t5/Analyzers/Getting-Symbols-in-VTune-Amplifier-2018/td-p/1129907

Have you tried turning the pdb from the sample which seems to work into yaml, analyze is and turn it back into pdb to check if it still works? Like eliminating the differences between those two to nail down the case for VTune choking.

 

Also in case you are not afraid of C++ you might look into https://github.com/rainers/cv2pdb which claims to be able to generate pdb files for D that Visual Studio can read (btw, can VS read yours?)

Edited March 17, 2021 by Stefan Glienke

[Anders Melander 1639]

10 minutes ago, Stefan Glienke said:

Could this be the case? https://community.intel.com/t5/Analyzers/Getting-Symbols-in-VTune-Amplifier-2018/td-p/1129907

Maybe. I'm a bit unsure about what they mean by symbols. In my implementation "symbols" are methods (name/offset/size) but I'm not including stack frame, parameter info, locals, return values etc. since I don't have that information available.

SymChk reports that I don't have "global symbols" but while I assumed that to mean global exports (which I don't supply) it might well be meaning the globals mentioned in the post.

 

17 minutes ago, Stefan Glienke said:

Have you tried turning the pdb from the sample which seems to work into yaml, analyze is and turn it back into pdb to check if it still works? Like eliminating the differences between those two to nail down the case for VTune choking. 

Good idea.

The round trip broke the pdb. VTune can no longer resolve and it doesn't report any errors. Just like with my pdb

I'll do a diff on the old and new tomorrow.

 

Maybe I should try with a newer version of VTune. I'm not too thrilled about asking for help on the VTune forum about an old unsupported version either (my community registration finally completed).

[Stefan Glienke 1905]

Well shoot me all the stuff (with fool proof instructions if there are any ^^) and I try it out on VTune 2020

[Guest]

Few thoughts and information on this

6 hours ago, Stefan Glienke said:

Have you tried turning the pdb from the sample which seems to work into yaml, analyze is and turn it back into pdb to check if it still works? Like eliminating the differences between those two to nail down the case for VTune choking.

This what i did in the past by finding the smallest pdb file and reverse engineering it, but it was for a plugin on a debugger, the debugger got an update broke the plugin and then the plugin got an update with newer pdb version and nothing working anymore, that is not point now, it seems Microsoft is sticking to RSDS for now.

 

VTune works and show perfectly debug information of binaries generated by FPC, while the debug information in FPC are DWARF format, VTune can handle the internal debug information and the FPC external file which have ".dbg" extension, so if you need an easy an easy to manipulate debug information then FPC is your friend for now.

6 hours ago, Stefan Glienke said:

Also in case you are not afraid of C++ you might look into https://github.com/rainers/cv2pdb 

Which does work perfectly and here is the thing, CodeView is different format from DWARF, but this tool supports DWARF also, so the FPC "dbg" files can be perfectly converted with this tool into 100% working with VTune "pdb" file, it also patch the exe.

combine the two above and you have an easy way to build pdb files that you fully control.

 

Also, external dbg DWARF files are attached to an exe differently from pdb files, it is an extra PE section with out of size additional few bytes starting with the size of these bytes which is $13 represented as 32bit little integer then ".gnu_debuglink" followied by 0, while the section is simply contain the dbg file name as 0 terminated string followed by its CRC32 checksum,(one look at the exe hex and you will understand it it) and that is it, here i want to mention when i removed that dbg file VTune searched for (EXEname).pdb automatically even though there is no pdb debug information in the header, this might be useful to exploit, (who knows ?).

 

The above screenshot are using FPC with external dbg files ( the internal debug information has the same result ), the following screenshot made after dbg converted to pdb using cv2pdb

You can see the converted one is better for the stack information, which is strange !, but yet it does show that addresses format play essential rule here.

 

So , i think VTune is reading and parsing your pdb file, but there is something wrong with RVA's and these should be adjusted accordingly, simple like that.

Also the MAP files data are relative to the PE section, so it is plausible cause.

Another also, i witnessed many discrepancies in MAP files like repeated entries ( the same relative address with the same exact procedure name allocated in different places even within the same MAP section), this might be also the case that your converted pdb fil contains repeated data that is triggering an no-go check for VTune in case it is building hash table for an addresses with a names, may be it is the case.

 

Hope that help.

[Anders Melander 1639]

So like @Stefan Glienke suggested I ran the VTune example application matrix.exe/matrix.pdb through llvm-pdbutil pdb2yaml to produce yaml and then again with yaml2pdb to produce a new pdb. VTune now failed to resolve addresses so I ran the updated pdb through llvm-pdbutil pdb2yaml once more and compared the first and second yaml file to see what had changed. The only significant change was that the PublicsStream section was now empty.

 

I had observed this empty PublicsStream earlier when testing the roundtrip of the yaml I produce but since I assumed that the pdb produced by llvm-pdbutil can actually be used with VTune I concluded that this was a section that wasn't required and so I disabled the output of it (I can also see in the llvm source that they haven't implemented a writer for the section).

 

I can now see that my assumption was incorrect. While LLVM might have the intention of producing pdb that can be used with VTune I haven't seen any proof that they have actually reached that goal. This means that at least half of this project has been a complete goose chase. Well at least I now know why it doesn't work.

 

10 hours ago, Stefan Glienke said:

Also in case you are not afraid of C++ you might look into https://github.com/rainers/cv2pdb which claims to be able to generate pdb files for D that Visual Studio can read

I looked at it early on and then decided that it was safer to use llvm-pdbutil than to try and port it to Delphi. Maybe I was wrong 🙂

Also it's cheating; It's using undocumented Visual Studio DLLs to manipulate the pdb files so it requires that VS is installed. If this was a part of the Win SDK I wouldn't have a problem with it but I think the dependency on VS makes it a no-go.

 

2 hours ago, Kas Ob. said:

VTune works and show perfectly debug information of binaries generated by FPC, while the debug information in FPC are DWARF format, VTune can handle the internal debug information and the FPC external file which have ".dbg" extension, so if you need an easy an easy to manipulate debug information then FPC is your friend for now.

I thought DWARF was for for Linux only and that VTune didn't support it on Windows...?

If I have understood you correctly you're saying that VTune works with DWARF on Windows both when it's linked into the exe and when it's external (with a reference from the EXE).

 

I haven't investigated the DWARF format yet but I know that it's at least documented (unlike LLVMs YAML) - and maybe I can even reuse some of  FPCs code to handle it.

 

3 hours ago, Kas Ob. said:

So , i think VTune is reading and parsing your pdb file, but there is something wrong with RVA's and these should be adjusted accordingly, simple like that.

Also the MAP files data are relative to the PE section, so it is plausible cause.

I believe we can conclude that whatever values I write is moot since the PublicsStream section is missing from the pdb and that alone is enough to for VTune to not use the line number information that is there.

 

Regardless of that; When you say RVA I assume you mean the PE section RVA as specified in the PE headers? The only place in the pdb that RVAs are references is in the "*Linker *" section.

Since the map file doesn't give me the RVA values I simply write the segment offset instead. I don't really understand why the pdb would need the RVA but if that's how it is then I will just have to deal with it. I guess I will have to read the map file and then extract the RVA values from the PE header in order to get all the info required to produce a pdb.

 

3 hours ago, Kas Ob. said:

Another also, i witnessed many discrepancies in MAP files like repeated entries ( the same relative address with the same exact procedure name allocated in different places even within the same MAP section), this might be also the case that your converted pdb fil contains repeated data that is triggering an no-go check for VTune in case it is building hash table for an addresses with a names, may be it is the case. 

I discard duplicate symbols based on segment+offset. Duplicate segment+name are allowed but only one is emitted.

I have seen any segment+offset duplicates.

[Stefan Glienke 1905]

16 minutes ago, Anders Melander said:

Also it's cheating; It's using undocumented Visual Studio DLLs to manipulate the pdb files so it requires that VS is installed. If this was a part of the Win SDK I wouldn't have a problem with it but I think the dependency on VS makes it a no-go.

Given its the "official" way to produce these files - I would not say that it's cheating. MS even published the "documentation" (as in "heres the code, figure it out yourself") on github: https://github.com/microsoft/microsoft-pdb

It if turns out to be the best way then I could live with the fact that I have to install a VS - one would even have to check if distributing the required dll would be permitted or if just installing VS for using these dlls requires a license if you are not eligible to use the Community Edition.

[Guest]

35 minutes ago, Anders Melander said:

If I have understood you correctly you're saying that VTune works with DWARF on Windows both when it's linked into the exe and when it's external (with a reference from the EXE).

Yes, as shown by screenshots, also the screenshot point was a little different, my point was if we assume FPC was generating right DWARF data then VTune should have handled and presented the same result from the external dbg file and the converted one to pdb, but this is not happening, and the result with pdb is more accurate or extended this means the data are there, but VTune is very strict on the type of the information and their presentation per scheme, hence my assumption that VTune is parsing the pbd from yaml2pdb but failed on very small detail.

 

Also peeking inside VTune, it seems there is punch of supported formats, but i can't be sure about their naming or standard, only see what it does looking for, like different sections with specific naming..etc

 

49 minutes ago, Anders Melander said:

I believe we can conclude that whatever values I write is moot since the PublicsStream section is missing from the pdb and that alone is enough to for VTune to not use the line number information that is there.

Not definitively, i could compile your code so i asked a friend to compile it for me, ( you are using inline var !), anyway i tested an app that does compile on both XE8 and FPC and just played around with the result.

 

When i mentioned RVA, and here to be clear RVA is relative address, i didn't mean explicitly the final memory RVA, but .. ,!!!?? to explain with sample will be much easier

MAP file contain such structure

 Start         Length     Name                   Class
 0001:00401000 000D75F0H .text                   CODE
 0002:004D9000 00000844H .itext                  ICODE
 0003:004DA000 00003B24H .data                   DATA
 0004:004DE000 000053E0H .bss                    BSS
 0005:00000000 00000018H .tls                    TLS
 0006:00400000 00000000H .pdata                  PDATA
....
  Address             Publics by Name
....
 0001:0000DFEC       SysInit.@InitExe
 0001:0000E038       SysInit.@_delayLoadHelper2
 0001:0000E318       SysInit.@_FUnloadDelayLoadedDLL2
 0001:0000E428       SysInit.@_HrLoadAllImportsForDll
 0004:00002C5C       SysInit.@_pfnDliFailureHook2
 0004:00002C58       SysInit.@_pfnDliNotifyHook2
 0001:0000DF48       SysInit.AllocTlsBuffer
 0003:00000C18       SysInit.DelayLoadHelper
 0001:0000E600       SysInit.Finalization
 0001:0000DEF0       SysInit.FreeLibrary
 0001:0000DF20       SysInit.GetLastError

Now as you see these SSSS:AAAAAAAA where SSSS is the section from the first table, while AA.. is the relative address to its section, and this should be translated to relative address to relative address from the first table,

so the problem might be within there addresses conversion , should it be relative to the section or the start of them all which if you notice is not in that MAP file at all, and it is the most important which is 00400000, and here if you see the problem with PDATA section and TLS section, anyway it will get complicated discussing the many situations where addresses beein wrongly converted from MAP into pdb using few steps, as the MAP file i think is broken at its core just mentioned at TEXT section 00401000 as this will defeat relocation table and ruin the experience for any DLL.

 

So i really believe building PDB from a map file is way easier and faster as all what is needed for VTune is procedures and their addresses, and using FPC and cv2pdb will make this many fold easier to check address against the debugged EXE with the PDB output and EXE PE header.

1 hour ago, Anders Melander said:

I have seen any segment+offset duplicates.

It is there ! and happens very often, yet i have Seattle as my last and uses XE8 with D2010 and D2009 most the time, the following is coming form the same file that been compiler with FPC but with XE8

[Anders Melander 1639]

19 minutes ago, Kas Ob. said:

the result with pdb is more accurate or extended this means the data are there, but VTune is very strict on the type of the information and their presentation per scheme, hence my assumption that VTune is parsing the pbd from yaml2pdb but failed on very small detail.

Another interpretation could be that VTune's PDB importer extracts more details than its DWARF importer, even if the files contain the same information.

 

25 minutes ago, Kas Ob. said:

VTune is parsing the pbd from yaml2pdb but failed on very small detail.

I believe the roundtrip test with VTune's matrix example proved that yaml2pdb produces PDBs that cannot be used with VTune.

The pdb worked with VTune before going through LLVM's pdb2yaml->yaml2pdb. It didn't work after.

 

26 minutes ago, Kas Ob. said:

you are using inline var !

Definitely. I have no idea about how they affect performance but they are incredible convenient and I think they improve the readability of the code.

 

40 minutes ago, Kas Ob. said:

the start of them all which if you notice is not in that MAP file at all, and it is the most important which is 00400000

Yes it is:

0006:00400000 00000000H .pdata                  PDATA

This corresponds to the ImageBase field in the PE header. I don't know what the deal is with the .tls section.

Anyway since all the offsets in the map file are relative, and the process can get reallocated to anywhere at run time, the section addresses are really just nice-to-know.

 

As far as I can see, if you know the actual ImageBase of a process, then the map file contains all the information required to get from physical address to method/function and source code line and vice versa.

 

52 minutes ago, Kas Ob. said:



That's not a duplicate.

The map file contains two list of symbols. One is ordered by name and the other by address so if you just do a text search any symbol will occur twice in the map file. I only read the first list and ignore the other.

 

 

[Guest]

34 minutes ago, Anders Melander said:

This corresponds to the ImageBase field in the PE header. I don't know what the deal is with the .tls section.

Be careful here, as PDATA is the most important section for debug information from debugger and disassembler point of view, as you can see here https://docs.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-runtime_function

This table is enough for debuggers to know where function/procedure begin, end and how to unwind.

PDATA should never have such value as above as wither it does exist and it is a dedicated section or doesn't exist with zero size and zero address.

Also these addresses in PDATA are the ones you see in pdb file.

 

I am attaching here a small project built with FPC and converted with cv2pdb

program Project1;

var
  T: Cardinal;

  procedure ALoop;
  var
    I: integer;
  begin
    for I := 0 to MaxInt div 8 do
      T:= Cardinal(T+1);
  end;

  procedure BLoop;
  var
    I: integer;
  begin
    for I := 0 to MaxInt div 8 do
      T:= Cardinal(T+1);
  end;

  procedure CLoop;
  var
    I: integer;
  begin
    for I := 0 to MaxInt div 8 do
      T:= Cardinal(T+1);
  end;

begin
  T := 0;
  ALoop;
  BLoop;
  CLoop;
  ExitCode := T;
end.  

and here the binaries , if you don't like the binary, then just compile with FPC and "use external debug symbols file" then use cv2pdb, both are working fine with VTune, and notice that XLoop functions are mentioned twice in the pdb, the second is irrelevant ! and can be removed (filled with 0) while VTune will still produce nice report and browse the source files. cv2pdb does refuse to handle 32bit due the size or something (like too small), but works fine with bigger projects.

 

SmallApp.zip

 

 

And at last my whole point was and is this : it is easier to build pdb from map directly as long you understand the required streams, one for names and one for lines numbers and one for source files, these are the minimal and i doubt you will need anything more, building these tables in memory then combine them in one pdb file is doable and will be fast.

[Anders Melander 1639]

9 minutes ago, Kas Ob. said:

Be careful here, as PDATA is the most important section for debug information from debugger and disassembler point of view, as you can see here https://docs.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-runtime_function

I'm not sure why that is relevant.

I only mentioned PDATA because you claimed that the map file doesn't contain the ImageBase value; I pointed out that it does because in your map example ImageBase is the same as the start offset of the PDATA segment. Generally the ImageBase value is probably just the offset with the lowest value from the segment list.

 

15 minutes ago, Kas Ob. said:

it is easier to build pdb from map directly as long you understand the required streams, one for names and one for lines numbers and one for source files, these are the minimal and i doubt you will need anything more, building these tables in memory then combine them in one pdb file is doable and will be fast.

Everything is easy once you know how to do it. I understand the MSF container format but I have no clear understanding of the internal structure of the PDB format it contains.

 

In hindsight it would have been faster to just learn what there is to know about the topic, but the fact that MS have stated that they'll change the format as they see fit, kinda turned me away from that idea. I've now also gotten the clear impression, from reading the LLVM source, there there are parts that even the LLVM project don't understand. For example the PublicsStream section which VTune apparently requires.

 

Anyway, I'm now learning about DWARF and how FPC handles it. Thanks for bringing that to my attention.

[David Heffernan 2300]

40 minutes ago, Kas Ob. said:

PDATA is the most important section for debug information from debugger and disassembler point of view

Isn't this the section that is not picked up when linking 64 bit .obj files? Hence leading to problems (like instant process termination) when an exception occurs in such linked code.

 

Or have Emba addressed that in more recent releases?

[Guest]

10 minutes ago, David Heffernan said:

Or have Emba addressed that in more recent releases?

I have no idea.

 

 

[Guest]

26 minutes ago, Anders Melander said:

I only mentioned PDATA because you claimed that the map file doesn't contain the ImageBase value; I pointed out that it does because in your map example ImageBase is the same as the start offset of the PDATA segment. Generally the ImageBase value is probably just the offset with the lowest value from the segment list.

ImageBase Value should be lower than any other segment/section as it should be pointing to the PE header beginning.

one more thing the right map file should be start with such 

 Start         Length     Name                   Class
 0001:00001000 000269E0H .text                   CODE
 0002:00028000 000004E8H .itext                  ICODE
 0003:00029000 00002BBCH .data                   DATA
 0004:0002C000 00004ED8H .bss                    BSS
 0005:00AAAAAA 0000000CH .tls                    TLS		// AAAAAA > 0002C00 ( or removed) also size should not be 0
 0006:00BBBBBB 00000000H .pdata                  PDATA		// BBBBBB > AAAAAAA ( or removed) also size should not be 0

Now that how map file should look like, and all will be relative to the start address which is not mentioned here as all sections will be resolved to SectionStart+(ImageBase address), so when there is a section with the a value like $400000 then most converters will fail to or seems to be failed while the failure is coming form the corrupt/wrong map data to begin with, also i mentioned i am not sure about the relative addresses in pdb are they points to sections or image base address or to the first one segment as beacon.

There is a tool map2dbg which might be working if the map file is right, but still need exe patching to be used by VTune.

[Anders Melander 1639]

For those following this thread:

 

[FPiette 367]

On 4/23/2020 at 9:36 AM, Fr0sT.Brutal said:

https://github.com/Fr0sT-Brutal/awesome-pascal#code-checkreview-debug

That's where I discovered GpProfiler2017.