Anders Melander 1798 Posted March 16, 2021 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. Share this post Link to post
Attila Kovacs 631 Posted March 16, 2021 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? Share this post Link to post
Attila Kovacs 631 Posted March 16, 2021 (edited) 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 Share this post Link to post
Anders Melander 1798 Posted March 16, 2021 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 Share this post Link to post
Attila Kovacs 631 Posted March 16, 2021 (edited) 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 Share this post Link to post
Anders Melander 1798 Posted March 16, 2021 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 Share this post Link to post
Anders Melander 1798 Posted March 16, 2021 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. 1 Share this post Link to post
Stefan Glienke 2014 Posted March 17, 2021 (edited) 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 Share this post Link to post
Anders Melander 1798 Posted March 17, 2021 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. Share this post Link to post
Anders Melander 1798 Posted March 17, 2021 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. Share this post Link to post
Stefan Glienke 2014 Posted March 17, 2021 (edited) 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 Share this post Link to post
Anders Melander 1798 Posted March 18, 2021 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). Share this post Link to post
Stefan Glienke 2014 Posted March 18, 2021 Well shoot me all the stuff (with fool proof instructions if there are any ^^) and I try it out on VTune 2020 Share this post Link to post
Guest Posted March 18, 2021 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. Share this post Link to post
Anders Melander 1798 Posted March 18, 2021 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. Share this post Link to post
Stefan Glienke 2014 Posted March 18, 2021 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. Share this post Link to post
Guest Posted March 18, 2021 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 Share this post Link to post
Anders Melander 1798 Posted March 18, 2021 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. Share this post Link to post
Guest Posted March 18, 2021 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. Share this post Link to post
Anders Melander 1798 Posted March 18, 2021 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. Share this post Link to post
David Heffernan 2352 Posted March 18, 2021 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? Share this post Link to post
Guest Posted March 18, 2021 10 minutes ago, David Heffernan said: Or have Emba addressed that in more recent releases? I have no idea. Share this post Link to post
Guest Posted March 18, 2021 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. Share this post Link to post
Anders Melander 1798 Posted April 3, 2021 For those following this thread: 2 1 Share this post Link to post
FPiette 384 Posted January 16, 2022 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. Share this post Link to post