flat assembler
Message board for the users of flat assembler.

Index > IDE Development > Fresh 1.0.06 pre-alpha

Goto page Previous  1, 2, 3
Author
Thread Post new topic Reply to topic
pelaillo
Missing in inaction


Joined: 19 Jun 2003
Posts: 878
Location: Colombia
pelaillo 27 Aug 2003, 07:38
JohnFound,
in the last couple of days I was doing some tests to try to run a program from source to memory, and today I see your post asking Privalov's regarding this. Because I was thinking in a sort of source level debugger and I have no idea how to do it or how Privalov's doing it, I will expose you my schema to see if it worth a look for FRESH project:

1. Compile each section to a memory page allocated inside the same address space as FRESH.
2. Load and prepare import modules as needed.
3. Create an array of pointers to the source code lines and the offsets from start code.
4. Start a new thread to "run" the program.
5. The main thread keeps an eye on execution point, showing progress on source.
6. Allow breakpoints, pause and step by step execution.
7. A nightmare in case of debugging thread applications (maybe not, but scared)
8. ....

For now on I'm still struggling with point 1 and 2, but I prefer to save my time if the schema is not feasible. Let me know what you think.

Thanks,
Post 27 Aug 2003, 07:38
View user's profile Send private message Yahoo Messenger Reply with quote
scientica
Retired moderator


Joined: 16 Jun 2003
Posts: 689
Location: Linköping, Sweden
scientica 27 Aug 2003, 14:07
Just one comment, I think that the debugger should be able to crash wothout taking donw the entire IDE, or atleast save all project files (and sak for other files to be save) - so that the risc of lossing data is minimal.

As for point 5, you don't mean follow every instruction in GUI when "running" the exe? (It would slow down things *a lot*, better have two run-modes, run - don't show the current execution point (update GUI when the app stops/is stopped), follow/trace - the slow mode that shows every instruciton step in the debugger GUI). Of couse stepping should be allowed.
And I'd like to see an possibillity to "skip" debugging of system dlls (Olly has om several occasions frozen the entire system when lurkjing in the sys. dlls, even thought I've told it not to do so... :/ )

7. Might not be, "simply" add a "execution monitor thread" for each thread - let the main debugger thread handle them (thus for a single threaded app there will be two debugger threads - one for the debugger and one for the main thread).

_________________
... a professor saying: "use this proprietary software to learn computer science" is the same as English professor handing you a copy of Shakespeare and saying: "use this book to learn Shakespeare without opening the book itself.
- Bradley Kuhn
Post 27 Aug 2003, 14:07
View user's profile Send private message Visit poster's website Reply with quote
roticv



Joined: 19 Jun 2003
Posts: 374
Location: Singapore
roticv 27 Aug 2003, 15:38
Quote:
Just one comment, I think that the debugger should be able to crash wothout taking donw the entire IDE, or atleast save all project files (and sak for other files to be save) - so that the risc of lossing data is minimal.

Hasty I suppose? The way round it is to wrap it round seh. That would prevent the debugger to crash. You don't see ollydbg crashing right?
Post 27 Aug 2003, 15:38
View user's profile Send private message Visit poster's website MSN Messenger Reply with quote
scientica
Retired moderator


Joined: 16 Jun 2003
Posts: 689
Location: Linköping, Sweden
scientica 27 Aug 2003, 15:47
roticv wrote:
You don't see ollydbg crashing right?

I can't remember crashing it - but on several occasions it has frozen (kinda like a crash - but no error message or self termination) the system while doing something in the system dlls, even thought I've told it to skip them...

_________________
... a professor saying: "use this proprietary software to learn computer science" is the same as English professor handing you a copy of Shakespeare and saying: "use this book to learn Shakespeare without opening the book itself.
- Bradley Kuhn
Post 27 Aug 2003, 15:47
View user's profile Send private message Visit poster's website Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3499
Location: Bulgaria
JohnFound 27 Aug 2003, 17:42
pelaillo wrote:
JohnFound,
in the last couple of days I was doing some tests to try to run a program from source to memory, and today I see your post asking Privalov's regarding this. Because I was thinking in a sort of source level debugger and I have no idea how to do it or how Privalov's doing it, I will expose you my schema to see if it worth a look for FRESH project:

1. Compile each section to a memory page allocated inside the same address space as FRESH.
2. Load and prepare import modules as needed.
3. Create an array of pointers to the source code lines and the offsets from start code.
4. Start a new thread to "run" the program.
5. The main thread keeps an eye on execution point, showing progress on source.
6. Allow breakpoints, pause and step by step execution.
7. A nightmare in case of debugging thread applications (maybe not, but scared)
8. ....
For now on I'm still struggling with point 1 and 2, but I prefer to save my time if the schema is not feasible. Let me know what you think.
Thanks,


Hi, pelaillo.
IMO, Windows have some Debug API and all windows debugers (Olly too) uses this API to debug applications. Every program can start new process in "Debug mode" and to have full control under execution instruction by instruction. I think that Fresh must use the same API for source level Debuger, only instead of disassembling debuging application, it will use real source code. Of course, if the user prefer, there will be "CPU" window with exact machine level code - for example for tracing parts of code without source or Windows DLL's. (Delphi source level debuger work similar way.)
Unfortunately I have no time to learn more about Debuging API just now, and I think it's too early to think about Debuger for Fresh, because we must wait Privalov to implement some new features of FASM - giving us tables with relations between labels and real addresses in compiled code.
Without this information, it's impossible to realize source level debuger.

Regards.
Post 27 Aug 2003, 17:42
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
pelaillo
Missing in inaction


Joined: 19 Jun 2003
Posts: 878
Location: Colombia
pelaillo 28 Aug 2003, 11:48
OK JohnFound,
I will wait for Privalov's work and in the meantime I will concentrate on some GDI stuff.
Thanks,
Post 28 Aug 2003, 11:48
View user's profile Send private message Yahoo Messenger Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.