Map program flow

This is a discussion on Map program flow within the C Programming forums, part of the General Programming Boards category; A simple list of all caller-callee function pairs is not sufficient to produce tracing-style output or graphs. You need more ...

A simple list of all caller-callee function pairs is not sufficient to produce tracing-style output or graphs. You need more information than that

Thanks again for all your input on this, and i see you later elaborate on the point above. It seems more clear now that the data I am using leads to difficulties in mapping because of that lack of information. The function internals are not considered and there are plans to try and combine that later yes. I am hoping to get some time at the weekend to work on this and post back.

edit:

If you had a third column identifying each call (say, a line number), you could include that in the above graph trivially

I just read this. I do have the line numbers in the data, and a couple of other columns also, It had crossed my mind the line numbers might be useful, I need to have another look at the source data and will post with the extra columns info.

I am finally getting some time to pick this up! I like the output graph in post #11 - That looks like the right reading style. The reason this is required - or being looked at is that debugging the codebase has become difficult - It has been written over a period of twenty years or more! And it has been managed in a rather 'arbitrary' way lets say..
So it has been suggested it will be useful to be able to build some documentation computationally, reading the code as it stands, and one useful thing is to be able to map possible paths

I checked the source data again - each row has the callee and call, the line number and the source code instruction- But that is only ever eg 'CALL MODULE B', And i also noticed the query is bringing back commented out calls, heh, ill have to have that sorted out!