|
From: | Brian Tiffin |
Subject: | Re: [open-cobol-list] tips on studying code bases |
Date: | Tue, 29 Apr 2014 23:33:01 -0400 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:28.0) Gecko/20100101 Firefox/28.0 SeaMonkey/2.25 |
Patrick wrote:
On 29/04/14 04:29 PM, Brian Tiffin wrote:Vincent Coen wrote:I would recommend you work on v2.1 and not v1.1. It will not be long before v2 series becomes the primary focus for all of us. As for tools well I have used doxygen in the past but I must admit it issues too much info much of which I find un-needed. I just write comments on my copy of the code but there again I have not had to look at the whole codebase only small segments. One project that I do wish to get involved in is to migrate the compiler to IBM MVS but I need to see if anyone else is involved doing so already. This will not be easy although it does have a gcc compiler but v3.4 and a earlier one around v3.3 along with the 'C' libraries. These are the last versions with support for the IBM mainframe architecture. Vince On 29/04/14 14:07, Patrick wrote:Hi Everyone Thanks again to Brian for yet another very helpful post and I am thankful for the private messages I received too. I think I am going to make another big push to learn the code base. I printed all the source code from 1.1. I think this is okay for bulk memorization but I wouldn't do it again, I ran cobc through cflow last night. It gives results like this: main() <int main (int argc, char **argv) at cobc.c:3669>: memset()cobc_sig_handler() <void COB_A_NORETURN cobc_sig_handler (int sig)at cobc.c:1478>: raise() kill() getpid() exit() continues on....It shows that raise, kill, getpid etc are callable from cobc_sig_handlerbut it can't tell which path of execution it will take. I was thinking of building a version with a whole bunch of printfstatements inside each function that would print the path of execution,"I am raise()" etc.I thought that I would then look at each function and then use ctags toview the argument definitions.Does this sound like a logical way to study the code base ? If not couldyou recommend some other techniques ?Patrick; along with what Vince suggests, and upgrading to 2.1 I'll run another Doxygen pass over the source tree. The doxy output is very approachable, and when an application is included in the pass (as with Gary's OCic interactive compiler in the example pass), the code flow is all nicely drawn in call graphs, clickable to source listings. For now, the 1.1 tree is at http://opencobol.add1tocobol.com/doxyapp/ (with application) /doxy (for just the compiler). There will be efforts put into the 2.1 development branch to enhance the Doxygen in source documentation comments. And yes, your mode of exploration should work. Look to the lines in the codegen that display current COBOL verb for the -ftraceall with COB_SET_TRACE Cheers, BrianThanks again Brian !This is a very helpful link. I also wanted to mention something neat i found with ctags today . I generated a file with cflow -r that shows the functions that call a given function. The regular cflow will list all the functions called including the same ones over and over again.I loaded files like this: gvim *.[ch] cflow-reverse-results tags then from within gvim loaded everything with this: set tags= path-to/tagsSo what I think is neat about this is that the cflow results are also clickable. I can still find the functions definitions from the cflow results.Thanks again and thanks to Vince -Patrick
Yeah, we kinda luck out in C ABI space. The amount of tooling available is pretty impressive.
Oh, and try bison -g parser.yfor a completely dense graphiv DOT description of the semantic tree. Useless really, other than wow.
(I didn't wait for dot to finish graphing, it would have tried to optimally uncross some two million edges, but sfdp laid down an image (after a while).
http://sourceforge.net/p/open-cobol/discussion/lounge/thread/cdee19eb/3678/attachment/opencobol-parser.png
Cheers, Brian
[Prev in Thread] | Current Thread | [Next in Thread] |