You may have found the cause of some of the breakage I've seen. I'm sure Richard will evaluate. I've digressed to version iccv701prop until the issues are resolved. There are notes in the OBEX listing about modules that fail on iccv702prop.
So what debugger approach will you take? GDB compatability would be sweet if feasible.
jazzed, my plan is to make a C# windows app that interfaces to debug code I integrate into the kernel and also a seperate debug cog.
Once I have something working I doubt it would be hard to have it also work with gdb (assuming gdb can work over a serial port) I personally don't like gdb, but I know many do. I use the MS Visual Studio debugger for native C++ on a daily basic for my day job, and for C# at home on hobby stuff.
In any case, I plan to freely share my modified kernel source, debug cog source, and the C# app source so that anyone can take it and run with whatever changes/additions they want.
Roy
p.s. I have a modifies kernel that should fix the bug, but I need to actually test it for even working at all [noparse]:)[/noparse].· I've spent the day going over it and adding comments and fixing the existing comments. Once I try it and verify it works I would gladly send you it to see if it resolves the problems you were having with 7.02.
I don't like any of the "gdb clients" on linux at all, but the underlying protocol definition is fair. Eclipse uses gdb and gdb can use serial port or network attached remote target ... that's where using the gdb protocol will pay quickly. And with Hippy's progress with DIY C, we could have a cross-platform C tool chain just about any day now.
I used MSVC++ 6.0 on my day job for 4 years and I am fond of old Visual Basic and new Visual C# for Windows programs ... much, much better GUI building experience than using Java [noparse]:)[/noparse]
finit overlay is done on purpose and the clibinterface is currently not used so the problems Steve found is... something else. I haven't have a chance to really looked into it though :-(....
Yeah I just figured out that clibinterface was not being used yet by compiled code.
So the line that causes a problem in Steve's VGA_Text project is the while(1); that is at the end.
What happens is that the compiler tries to use FCACHE for this while(1); line and ends up placing itself one instruction just previous to where it should go.
If I change the line to be while(1) { ii++; } then it works fine and still uses FCACHE for the while loop. It looks like if the loop is too short (in the while(1);·case, just·one instruction) the compiler is producing bad FCACHE instructions.
Hope this helps narrow down the problem.
Roy
Post Edited (Roy Eltham) : 9/8/2008 6:20:18 AM GMT
Comments
You may have found the cause of some of the breakage I've seen. I'm sure Richard will evaluate. I've digressed to version iccv701prop until the issues are resolved. There are notes in the OBEX listing about modules that fail on iccv702prop.
So what debugger approach will you take? GDB compatability would be sweet if feasible.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Once I have something working I doubt it would be hard to have it also work with gdb (assuming gdb can work over a serial port) I personally don't like gdb, but I know many do. I use the MS Visual Studio debugger for native C++ on a daily basic for my day job, and for C# at home on hobby stuff.
In any case, I plan to freely share my modified kernel source, debug cog source, and the C# app source so that anyone can take it and run with whatever changes/additions they want.
Roy
p.s. I have a modifies kernel that should fix the bug, but I need to actually test it for even working at all [noparse]:)[/noparse].· I've spent the day going over it and adding comments and fixing the existing comments. Once I try it and verify it works I would gladly send you it to see if it resolves the problems you were having with 7.02.
I used MSVC++ 6.0 on my day job for 4 years and I am fond of old Visual Basic and new Visual C# for Windows programs ... much, much better GUI building experience than using Java [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
So the line that causes a problem in Steve's VGA_Text project is the while(1); that is at the end.
What happens is that the compiler tries to use FCACHE for this while(1); line and ends up placing itself one instruction just previous to where it should go.
If I change the line to be while(1) { ii++; } then it works fine and still uses FCACHE for the while loop. It looks like if the loop is too short (in the while(1);·case, just·one instruction) the compiler is producing bad FCACHE instructions.
Hope this helps narrow down the problem.
Roy
Post Edited (Roy Eltham) : 9/8/2008 6:20:18 AM GMT