GoP

[donkey]

I'm still thinking of creating a profiler type application for GoAsm and have been working on it on and off for a while. I need to test the direction I have chosen and get some feedback about what it might support so I have uploaded the first draft. It doesn't do much but allow you to insert breakpoints and extract performance counter information when the breakpoints are reached but it is a fairly complex program already. Once you have a program opened the profiler will pause and allow you to choose the symbols to track. To set a breakpoint simply double click on an entry in the code labels and select Set. You can view the source code for the label and also add a comment as well. After the breakpoints are set click start and the timing information will be displayed. I would like input on what to do with the timing information (ie analysis) and also ideas on how to improve the output.

Since the project includes the proper version of various DLL's it is rather large in size (around 600K) and so it can't be uploaded here. I have made it available (temporarily) through my website...

http://www.quickersoft.com/donkey/files/GoP.zip

You should download the header project in order to build it as there are a few corrections that are not part of any release.

Note that though the preferred symbol path is the executable since this is a GoAsm targeted project, MASM pdb symbols are supported as well so the profiler should function equally well with MASM projects.

Edgar

[donkey]

I had a bit of time on the weekend to add some features to the application, I have added the ability to view the sections raw data in a hex viewer and also to view the direct imports of the executable. There were 9 downloads...

[donkey]

Well, only 16 or so downloads and no real ideas yet so I'll probably remove the file soon and see if I can't come up with some stuff myself. For now I'm working on reading the code section directly from the file as opposed to reading the debugees memory, that way any breakpoints that are set won't be changed to INT3 and the process won't have to be running to view code dumps. I am also considering writing a disassembler as it could give me more control over heuristics like finding the end of a procedure, something I am having trouble with because I have no idea how to do it. I was thinking about scanning ahead until I found the next procedure entry point and using that but there must be a more reliable way. Mapping the procedure start and end is critical to the project, much of my ideas for timing information involve execution times for procedures so this is something I have to figure out...

[jj2007]

I was thinking about scanning ahead until I found the next procedure entry point and using that but there must be a more reliable way.

At least you have the ideal testbed here in the Forum. Just search for "frameless" or for Lingo's posts...
:bg

[donkey]

I was thinking about scanning ahead until I found the next procedure entry point and using that but there must be a more reliable way.

At least you have the ideal testbed here in the Forum. Just search for "frameless" or for Lingo's posts...
:bg

Hi jj2007,

Well, I'm not overly concerned about non-standard code for now, just getting the start and end of a standard procedure right. I am currently thinking that I can scan ahead to the next procedure (or the end of the code section) then back up til I find a RET instruction, this should be fairly reliable for standard procedures as long as no one tries to trick it (which would be easy). For now I am working under the assumption that the user will want reliable data during the tests and can always obfuscate later.

[BlackVortex]

This sure is a niche tool. At some point I got to learn how to produce symbols with goasm, I've always wanted to see my source code in Olly. (It's possible, right ?)

[donkey]

This sure is a niche tool. At some point I got to learn how to produce symbols with goasm, I've always wanted to see my source code in Olly. (It's possible, right ?)

No, since line numbers are not stored as a part of the object file source level debugging is not possible with GoAsm programs. This has always been something I have seen as a shortcoming (albeit minor) in GoAsm since it can make debugging more difficult. Symbols in GoAsm are pretty much the same as in MASM though less detail is included, all labels either code or data are added to the symbol table, the only major difference is that GoAsm stores them in the executable while MASM uses a separate PDB file. To build a debug version (ie with symbols) just use the /debug switch on the GoLink command line.