Virtual AGC (Apollo Guidance Computer) debugging in C::B

[ohommes]

 All,

I have been working for sometime to extend the Virtual AGC to support a full GDB/MI interface (replacing a proprietary one). Now that most of the command-line interface for gdb is working for the AGC emulator I thought I'd send a notice to this forum letting you know you can now visually debug the original Code Colossus249 (Apollo Command Module) and Lumiary131 (Apollo Lunar Module) under Code:Blocks control and launch the external simulators from it. Active Interrupts will show as different active threads in C::B.

If interested visit http://virtualagc.googlecode.com and checkout the Wiki pages and in particular Visual debugging it has a small screen shot showing C::B debugging Colossus249 in an interrupt service routine. To work with the AGC and DSKY you need some extensive knowledge but I also provide some links to reference the original site where it all started which currently most of the background to get you off the ground. A working snapshot of the svn code base is needed to fully debug the original code. The download area only has a binary version of the emulator but doesn't have the original sources bundled with it.

Recently there was a post at slashdot discussion the oldest code still running. I guess the MIT Apollo program code maybe a candidate here since it is code from the mid 60's. Anyway if you are intrested  in Embedded development and enjoy playing and hacking around with the software of humans greatest adventure then checkout the site above. I have both Linux and Windows version of Code::Blocks 8.02 working with the AGC. It is really exciting to see 60's software in a 2008 IDE.

I wrote a document see yaScripts/CodeBlocks in the source tree explain how to integrate the YUL assembler and add the AGC syntax highlighting. So not only does C::B support C++ development it also supports AGC development using the YUL assembler.

Enjoy,


Onno Hommes

[ohommes]

As part of the 40th anniversary of the Apollo 11 flight we changed our extension from ".s" to ".agc" and ".aea" to allow for proper syntax-highlighting on the googlecode servers. Immediately the sources became of category other and one can no longer single step through the assembler code.

Tried the following:
Updated the File extension handler to open the .agc and .aea with the Code blocks editor and updated the ASM Sources category for the project to also recognize *.agc and *.aea. However no matter what I do the files remain grayed out and the single step refuses to show the source location while stepping through the code in debug mode yet all windows update except for the editor window. SO the registers nicely change with every step so does the call stack correctly. However it seems unless the file has a .s extension you cannot single step. This is horrible since we are promoting this as our primary debugger for the virtual agc environment. Any thoughts on how to get the new extensions to not be grayed out and allow for single stepping? Every thing else including syntax highlighting and opening in the editor after updating the file extension handler section works. This all worked fine with the .s extension. HELP!!!!

[stahta01]

Not an gdb guru; but it seems to be an gdb issue and not directly an Code::Blocks issue.

try finding where to can do the following.
set language asm
set extension-language .ext language

See web page
https://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gdb/show.html

Tim S.

[ohommes]

Just to give you more input. It is not the gdb, I am sure of this because the same debugger session works fine in KDbg or Emacs. The actual fullname frames as set with the --fullname flag are produced properly. What is striking to me is that eventhough I registered my new extension with the ASM Sources my source still remain grayed out in the project browser as if they are still considered other source files. registering a .s file shows a nice non-grayed filename in the project browser. So before even starting the debugger Code::Blocks behaves differently just based on the extension even if the extension is properly registered with: Syntax Highlighting, File Categories and File Extension Handler. To me this seems like Code::Blocks only "paints" the default extensions file names black and the non-standard always grayed-out and consequently refuses to use the editor for the single step update just because the extension is different. I am sure you can try this yourself with 8.02; Just register a file with extension .agc and one with .s and observe how the .s shows as a black font (I think indicating this is source) and the .agc as grayed-out (indicating "unknown what this is").

I guess I need to dive into the Code:Blocks project manager first to determine why the file appears grayed out even when the extension is registered with the types and categories setting.

Anyone else have any thoughts?

[ohommes]

I think the issue is related to the hard coded types of CB. See associations.cpp. In this C++ file there is a array symbol knownTypes containing file extensions with their respective  description and icons. I believe this is used to determining the color and icon of the filename in the ProjectManager as well as the relation between the editor for debugging. I'll patch a binary to see if this assumption is correct.

[ohommes]

Okay I just confirmed it just renaming a source file from something.agc to something.s makes the file capable of debugging again. Why does code blocks have this weird limitation build in. If a file is a source file no matter what it should be possible to use it as a file in the debugger and have the IDE set the line indicator when debugging to show where you are. If I have a file name a.s which jumps to a file b.agc which then calls c.s then while I am in a.s I get the nice indication in the editor during debugging where I am, when jumping into the b.agc file it stops and when jumping to c.s it starts again. So clearly it is based on the extension whether or not CodeBlocks enables source stepping. This is weird especially when all the other debug functions work. It is just that the IDE editor is afraid of opening a non-text file.

Does anyone have a solution for this?

[stahta01]

I do NOT use the debugger; so, I can not test patch or confirm this issue.
But, I do build Code::Blocks a lot and if it is in code blocks I think it is it the code below.

from filefilters.cpp

Code

const wxString FileFilters::S_EXT                        = _T("s");

from globals.cpp

Code

FileType FileTypeOf(const wxString& filename)
{
    wxString ext = filename.AfterLast(_T('.')).Lower();

    if (ext.IsSameAs(FileFilters::ASM_EXT) ||
        ext.IsSameAs(FileFilters::C_EXT) ||
        ext.IsSameAs(FileFilters::CC_EXT) ||
        ext.IsSameAs(FileFilters::CPP_EXT) ||
        ext.IsSameAs(FileFilters::CXX_EXT) ||
        ext.IsSameAs(FileFilters::INL_EXT) ||
        ext.IsSameAs(FileFilters::S_EXT) ||
        ext.IsSameAs(FileFilters::SS_EXT) ||
        ext.IsSameAs(FileFilters::S62_EXT) ||
        ext.IsSameAs(FileFilters::D_EXT) ||
        ext.IsSameAs(FileFilters::F_EXT) ||
        ext.IsSameAs(FileFilters::F77_EXT) ||
        ext.IsSameAs(FileFilters::F90_EXT) ||
        ext.IsSameAs(FileFilters::F95_EXT) ||
        ext.IsSameAs(FileFilters::JAVA_EXT)
       )
        return ftSource;

from debuggergdb.cpp

Code

void DebuggerGDB::SyncEditor(const wxString& filename, int line, bool setMarker)
{
    if (setMarker)
        ClearActiveMarkFromAllEditors();
    FileType ft = FileTypeOf(filename);
    if (ft != ftSource && ft != ftHeader && ft != ftResource)
        return; // don't try to open unknown files

Tim S.

[stahta01]

Possible patch it needs testing to confirm it fixes the problem and to confirm it compiles.

Code

Index: src/sdk/scripting/bindings/sc_consts.cpp
===================================================================
--- src/sdk/scripting/bindings/sc_consts.cpp	(revision 5730)
+++ src/sdk/scripting/bindings/sc_consts.cpp	(working copy)
@@ -195,6 +195,8 @@
         BIND_WXSTR_CONSTANT_NAMED(FileFilters::MSVC6_WORKSPACE_EXT, "EXT_MSVC6_WORKSPACE");
         BIND_WXSTR_CONSTANT_NAMED(FileFilters::MSVC7_EXT, "EXT_MSVC7");
         BIND_WXSTR_CONSTANT_NAMED(FileFilters::MSVC7_WORKSPACE_EXT, "EXT_MSVC7_WORKSPACE");
+        BIND_WXSTR_CONSTANT_NAMED(FileFilters::AEA_EXT, "EXT_AEA");
+        BIND_WXSTR_CONSTANT_NAMED(FileFilters::AGC_EXT, "EXT_AGC");
         BIND_WXSTR_CONSTANT_NAMED(FileFilters::ASM_EXT, "EXT_ASM");
         BIND_WXSTR_CONSTANT_NAMED(FileFilters::D_EXT, "EXT_D");
         BIND_WXSTR_CONSTANT_NAMED(FileFilters::F_EXT, "EXT_F");
@@ -231,6 +233,8 @@
         BIND_WXSTR_CONSTANT_NAMED(FileFilters::MSVC6_WORKSPACE_DOT_EXT, "DOT_EXT_MSVC6_WORKSPACE");
         BIND_WXSTR_CONSTANT_NAMED(FileFilters::MSVC7_DOT_EXT, "DOT_EXT_MSVC7");
         BIND_WXSTR_CONSTANT_NAMED(FileFilters::MSVC7_WORKSPACE_DOT_EXT, "DOT_EXT_MSVC7_WORKSPACE");
+        BIND_WXSTR_CONSTANT_NAMED(FileFilters::AEA_DOT_EXT, "DOT_EXT_AEA");
+        BIND_WXSTR_CONSTANT_NAMED(FileFilters::AGC_DOT_EXT, "DOT_EXT_AGC");
         BIND_WXSTR_CONSTANT_NAMED(FileFilters::ASM_DOT_EXT, "DOT_EXT_ASM");
         BIND_WXSTR_CONSTANT_NAMED(FileFilters::D_DOT_EXT, "DOT_EXT_D");
         BIND_WXSTR_CONSTANT_NAMED(FileFilters::F_DOT_EXT, "DOT_EXT_F");
Index: src/sdk/globals.cpp
===================================================================
--- src/sdk/globals.cpp	(revision 5730)
+++ src/sdk/globals.cpp	(working copy)
@@ -210,7 +210,9 @@
 {
     wxString ext = filename.AfterLast(_T('.')).Lower();
 
-    if (ext.IsSameAs(FileFilters::ASM_EXT) ||
+    if (ext.IsSameAs(FileFilters::AEA_EXT) ||
+        ext.IsSameAs(FileFilters::AGC_EXT) ||
+        ext.IsSameAs(FileFilters::ASM_EXT) ||
         ext.IsSameAs(FileFilters::C_EXT) ||
         ext.IsSameAs(FileFilters::CC_EXT) ||
         ext.IsSameAs(FileFilters::CPP_EXT) ||
Index: src/sdk/filefilters.cpp
===================================================================
--- src/sdk/filefilters.cpp	(revision 5730)
+++ src/sdk/filefilters.cpp	(working copy)
@@ -147,6 +147,8 @@
 const wxString FileFilters::MSVC7_WORKSPACE_EXT          = _T("sln");
 const wxString FileFilters::XCODE1_EXT                   = _T("xcode");
 const wxString FileFilters::XCODE2_EXT                   = _T("xcodeproj");
+const wxString FileFilters::AEA_EXT                      = _T("aea");
+const wxString FileFilters::AGC_EXT                      = _T("agc");
 const wxString FileFilters::ASM_EXT                      = _T("asm");
 const wxString FileFilters::D_EXT                        = _T("d");
 const wxString FileFilters::F_EXT                        = _T("f");
@@ -197,6 +199,8 @@
 const wxString FileFilters::MSVC7_WORKSPACE_DOT_EXT          = _T('.') + FileFilters::MSVC7_WORKSPACE_EXT;
 const wxString FileFilters::XCODE1_DOT_EXT                   = _T('.') + FileFilters::XCODE1_EXT;
 const wxString FileFilters::XCODE2_DOT_EXT                   = _T('.') + FileFilters::XCODE2_EXT;
+const wxString FileFilters::AEA_DOT_EXT                      = _T('.') + FileFilters::AEA_EXT;
+const wxString FileFilters::AGC_DOT_EXT                      = _T('.') + FileFilters::AGC_EXT;
 const wxString FileFilters::ASM_DOT_EXT                      = _T('.') + FileFilters::ASM_EXT;
 const wxString FileFilters::D_DOT_EXT                        = _T('.') + FileFilters::D_EXT;
 const wxString FileFilters::F_DOT_EXT                        = _T('.') + FileFilters::F_EXT;
Index: src/include/filefilters.h
===================================================================
--- src/include/filefilters.h	(revision 5730)
+++ src/include/filefilters.h	(working copy)
@@ -72,6 +72,8 @@
     extern const DLLIMPORT wxString MSVC7_WORKSPACE_EXT;
     extern const DLLIMPORT wxString XCODE1_EXT;
     extern const DLLIMPORT wxString XCODE2_EXT;
+    extern const DLLIMPORT wxString AEA_EXT;
+    extern const DLLIMPORT wxString AGC_EXT;
     extern const DLLIMPORT wxString ASM_EXT;
     extern const DLLIMPORT wxString D_EXT;
     extern const DLLIMPORT wxString F_EXT;
@@ -112,6 +114,8 @@
     extern const DLLIMPORT wxString MSVC7_WORKSPACE_DOT_EXT;
     extern const DLLIMPORT wxString XCODE1_DOT_EXT;
     extern const DLLIMPORT wxString XCODE2_DOT_EXT;
+    extern const DLLIMPORT wxString AEA_DOT_EXT;
+    extern const DLLIMPORT wxString AGC_DOT_EXT;
     extern const DLLIMPORT wxString ASM_DOT_EXT;
     extern const DLLIMPORT wxString D_DOT_EXT;
     extern const DLLIMPORT wxString F_DOT_EXT;
Index: src/src/associations.cpp
===================================================================
--- src/src/associations.cpp	(revision 5730)
+++ src/src/associations.cpp	(working copy)
@@ -47,6 +47,8 @@
     { FileFilters::RESOURCE_EXT,        _T("resource file"),                10 },
     { FileFilters::XRCRESOURCE_EXT,     _T("XRC resource file"),            10 },
 
+    { FileFilters::AEA_EXT,             _T("ASM source file"),               2 },
+    { FileFilters::AGC_EXT,             _T("ASM source file"),               2 },
     { FileFilters::ASM_EXT,             _T("ASM source file"),               2 },
     { FileFilters::S_EXT,               _T("ASM source file"),               2 },
     { FileFilters::SS_EXT,              _T("ASM source file"),               2 },

Tim S.

[ohommes]

Okay I'll try to give this patch a try soon and let you know if this allows it to open the files. I think in general all files that are added to the file types and categories which are added to the base groups should be allowed to be opened. But for now I'll try this patch. I think this should work based on what I can see in the code but nevertheless it needs testing.

Thanks in advance!!

[ohommes]

Still trying to validate this patch. I am currently going through the hassle and setup of compiling CodeBlocks with a very very old gcc compiler (3.2.3). Compiling and archiving works fine from the existing 8.02 but I am battling the correct wxWidgets setup. I found a wiki that explains the steps so I'll try that and see how far it goes.

[stahta01]

Still trying to validate this patch. I am currently going through the hassle and setup of compiling CodeBlocks with a very very old gcc compiler (3.2.3). Compiling and archiving works fine from the existing 8.02 but I am battling the correct wxWidgets setup. I found a wiki that explains the steps so I'll try that and see how far it goes.

I would not try anything older that 3.4 myself; I have no idea if it will work with GCC 3.2.

Tim S.

[ohommes]

Okay I have tried with a gcc 3.2.3 but after many slow gains it just doesn't seem to get through it. I'll have to migrate to a later version of gcc. I just need to verify that all the other things I build work with the new gcc version. I remember in 4.x there was a problem with the trailing slash of an include directory. Hopefully later gcc versions 5.x have this fixed otherwise I can't upgrade.

Anyway I have not forgotten about this and I think the patch you created will do the trick. I just want to officially confirm your patch works.

[ohommes]

Okay the patch works but this will only solve it for my specific issue. Since C::B supports all the bells and whistles to allow adding in other tool chains why is it limiting in the debugger which files can be opened. You can add your own lexer configuration, add your types to the editor, add to the file classification , compile anything you want yet the debugger has this nice one liner with:

Code

    if (ft != ftSource && ft != ftHeader && ft != ftResource)
        return; // don't try to open unknown files

I don't get it if the gdb or in my case another debug tool tells in which source file it is why does C::B slam the door on unknown types. Maybe there should be an option to allow any type or use the dynamic file categories but hard-coding the basic file extensions seems like an unnecessary limitation.