Message board for the users of flat assembler.
> Windows > PDB files generation
|Do you need PDB files?|
|Total Votes : 28|
S.T.A.S. 22 Aug 2004, 10:04
After some researching, I found that FASM is able to generare PDB files.
Realisation of this feature is very sloppy at the moment, but still it works
Here are a few steps to turn it on:
1. Download FASM with listing from this thread, and extract archive to fasm sourse tree.
2. Open 'FORMATS.INC' file and do following modification:
3. Compile fasm\SOURCE\LISTING\WIN32\FASM.ASM
db 4,'data',19h,6 db 5,'debug',1Ah,6 ; <- add this line db 11,'discardable',19h,25
Now FASM is able to generate 'DEBUG' section.
4. Use 'fasmd.js' script (see attachment) to build "debug" version of your program.
5. Open compiled program with OllyDebug, go to View -> Source files and open *.LST file.
Also, now you may try to use some other programs that requires PDB files.
(I use them with AMD CodeAnalist performance analiser, which can be downloaded for free from AMD site: http://cdrom.amd.com/devconn/ )
Well, now about problems
PDB format is not documented. Some description of old (version 2) format can be found in 'Undocumented Windows 2000 secrets' by Sven B. Schreiber.
Current format is 'MSF 7.00', you may read some information about it at Jeremy Gordon's site.
I found no more information yet (if you know some, fell free to send me a link
At the moment only line numbers information is added to PDB, this allows some 'source level debugging' capabilities. Nothing like 'simbolic info' is added (well, I don't know is it necessary if we have the source ).
The process of building PDB files is somewhat tricky - script runs FASM for 3 times.
The first one is to determine size of exe file. This is necessary to correctly build CODE_VIEW directory, because there's no internal capabilities in FASM for such purpose. (some internal variable or something like RVA to determine physical offset from beginning of file would be very nice).
At the second time script adds one line at the end of the source and compiles exe with additional debug section.
After this, listing file is parsed, dummy asm file is generated and compiled into PDB.
Well, this is just first attempt, that's why it's silly script
Also, there's one known problem with PDBs - CodeAnalist crashes when I try to open FASM compiled with PDB (BTW, FASM.ASM should be renamed, otherwise script fails beceause FASM can't overwrite itself).
All other files I tryed seems to work with it, maybe this is because of very big PDB size (I'll continue its format research in hope to solve this problem)
Again, FASM fails to generate listing from FRESH source..
Of cource, there are lot of things to be improved in the future, nevertheless, I hope this can be useful now.
|22 Aug 2004, 10:04||
JohnFound 05 Oct 2004, 13:11
Hm, Fresh collects a lot of data about compiled program during compilation. (actually the whole symbols tree with final values) Maybe you can use this information instead of parsing .lst files?
|05 Oct 2004, 13:11||
S.T.A.S. 06 Oct 2004, 10:12
Well, .lst file is being parced not to collect symbols, but to make 'source file' linked to PDB - that is the file where each string is related to some data into compiled .exe.
So, when one opens this 'debug version' program with OllyDebug, he may also open 'source file' and navigate through it, say click on 'invoke foo,2' in line 20, and see actuay assembled 'push 2 etc'
I know script is not the best solution, but the problem is not to parse source, but to add needed data to PDB. MS provides API to retrieve information from this database, not to add.
So, adding symbols to PDB is, of cource, good idea, but it isn't so easy ;(
Actually, simpler solution was introduced by Foamplast - just export symbols by names - and the names will be available in OllyDebug.
BTW, I didn't include any precompiled examples in above .zip, because pathes to files are hardcoded into PDB, so it's important not to move files between directories, otherwise PDB won't work.
|06 Oct 2004, 10:12||
< Last Thread | Next Thread >
Copyright © 1999-2023, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.