Is there some Amiga tools for C langage developpement that will do :
Functions-tree from a C source : what function call another function,etc...
Functions-adresse from binary : extract function names and offsets : thing like function foo() begin at offset 2000 and finish at offset 14000 (so is 12000 long) So will know where is each function in binary and what size it occupy
Functions-tree from a C source : what function call another function,etc...
You mean command line or gui one ? For gui one: codebench.
Quote:
Functions-adresse from binary : extract function names and offsets : thing like function foo() begin at offset 2000 and finish at offset 14000 (so is 12000 long) So will know where is each function in binary and what size it occupy
That one imho can be mix of objdump + grep , like:
Quote:
ram:> objdump -d binary | grep ">:"
Will show you all the functions names your binary have and offset. Size of function will be next ">:" founded. Probably some script will be better , but main idea is objdump + grep.
Functions-tree from a C source : what function call another function,etc...
From Source I'm not sure, couldn't be that hard to script it with python.
Run time, have looked at gcov ? I believe it works. (as opposed to gprof which doesn't work on SAMs)
Quote:
Functions-adresse from binary : extract function names and offsets : thing like function foo() begin at offset 2000 and finish at offset 14000 (so is 12000 long) So will know where is each function in binary and what size it occupy
Objdump, but optimisation may make simplistic start / stop less meaningful.
5.Stock:Backup_Datas/Gui4Cli/Dev/Gui4Cli_Dev/G4C_18> gcc guis:Dev/Gui4Cli_Dev/G4C_18/Gui.c -fprofile-arcs -ftest-coverage -gstabs -lauto -N -o g18:gui4clid In file included from guis:Dev/Gui4Cli_Dev/G4C_18/Gui.c:105: guis:Dev/Gui4Cli_Dev/G4C_18/clip.h: In function 'ClipOpen': guis:Dev/Gui4Cli_Dev/G4C_18/clip.h:29: warning: comparison is always true due to limited range of data type 5.Stock:Backup_Datas/Gui4Cli/Dev/Gui4Cli_Dev/G4C_18> gcov gui4clid gui4clid.gcno:cannot open graph file 5.Stock:Backup_Datas/Gui4Cli/Dev/Gui4Cli_Dev/G4C_18> gcov -f gui4clid gui4clid.gcno:cannot open graph file
@joerg too bad, i can't get rid of the "cannot open graph file"
7.Stock:Backup_Datas/Gui4Cli/Dev/Gui4Cli_Dev/G4C_18> gcc guis:Dev/Gui4Cli_Dev/G4C_18/Gui.c -fprofile-arcs -ftest-coverage -gstabs -lauto -N -o g18:gui4clid In file included from guis:Dev/Gui4Cli_Dev/G4C_18/Gui.c:105: guis:Dev/Gui4Cli_Dev/G4C_18/clip.h: In function 'ClipOpen': guis:Dev/Gui4Cli_Dev/G4C_18/clip.h:29: warning: comparison is always true due to limited range of data type 7.Stock:Backup_Datas/Gui4Cli/Dev/Gui4Cli_Dev/G4C_18> gui4clid ***Command 'gui4clid' returned with unfreed signals 02000000! // on quitting, 7.Stock:Backup_Datas/Gui4Cli/Dev/Gui4Cli_Dev/G4C_18> gcov gui4clid gui4clid.gcno:cannot open graph file 7.Stock:Backup_Datas/Gui4Cli/Dev/Gui4Cli_Dev/G4C_18> gcov -f gui4clid gui4clid.gcno:cannot open graph file 7.Stock:Backup_Datas/Gui4Cli/Dev/Gui4Cli_Dev/G4C_18> gui4 gui4clid // no unfreed signals on quitting when the gui4 launcher is used 7.Stock:Backup_Datas/Gui4Cli/Dev/Gui4Cli_Dev/G4C_18> gcov gui4clid gui4clid.gcno:cannot open graph file 7.Stock:Backup_Datas/Gui4Cli/Dev/Gui4Cli_Dev/G4C_18> gcov -f gui4clid gui4clid.gcno:cannot open graph file
too bad, i can't get rid of the "cannot open graph file"
7.Stock:Backup_Datas/Gui4Cli/Dev/Gui4Cli_Dev/G4C_18> gcc guis:Dev/Gui4Cli_Dev/G4C_18/Gui.c -fprofile-arcs -ftest-coverage -gstabs -lauto -N -o g18:gui4clid In file included from guis:Dev/Gui4Cli_Dev/G4C_18/Gui.c:105: guis:Dev/Gui4Cli_Dev/G4C_18/clip.h: In function 'ClipOpen': guis:Dev/Gui4Cli_Dev/G4C_18/clip.h:29: warning: comparison is always true due to limited range of data type 7.Stock:Backup_Datas/Gui4Cli/Dev/Gui4Cli_Dev/G4C_18> gui4clid ***Command 'gui4clid' returned with unfreed signals 02000000! // on quitting, 7.Stock:Backup_Datas/Gui4Cli/Dev/Gui4Cli_Dev/G4C_18> gcov gui4clid gui4clid.gcno:cannot open graph file 7.Stock:Backup_Datas/Gui4Cli/Dev/Gui4Cli_Dev/G4C_18> gcov -f gui4clid gui4clid.gcno:cannot open graph file 7.Stock:Backup_Datas/Gui4Cli/Dev/Gui4Cli_Dev/G4C_18> gui4 gui4clid // no unfreed signals on quitting when the gui4 launcher is used 7.Stock:Backup_Datas/Gui4Cli/Dev/Gui4Cli_Dev/G4C_18> gcov gui4clid gui4clid.gcno:cannot open graph file 7.Stock:Backup_Datas/Gui4Cli/Dev/Gui4Cli_Dev/G4C_18> gcov -f gui4clid gui4clid.gcno:cannot open graph file
Two things:
1. gcov [Options] *SOURCEFILE*
ie not program name
2. you need to link with -lunix else the gcov writes the gdca file to the wrong place.
3. Fix that warning!
Quote:
guis:Dev/Gui4Cli_Dev/G4C_18/clip.h: In function 'ClipOpen': guis:Dev/Gui4Cli_Dev/G4C_18/clip.h:29: warning: comparison is always true due to limited range of data type
thanks, i am making progress i understand that to generate the graph file i have to mention all source files included with gui.c on the gcov command list. I get a command line that is too long for the CLI bufffer I suppose there is a way to split such long lines, but if i ever knew i forgot about it. Can you remind me of this, or is there an other way to solve the problem ?
thanks, i am making progress i understand that to generate the graph file i have to mention all source files included with gui.c on the gcov command list.
I'm not sure, if the files are included, whether they need seperate entries or not.
Quote:
I get a command line that is too long for the CLI bufffer
Just how many files are you including in the GUI.c files? I never ever managed to type a command that was too long, I just tried and gave up after 1500 characters. I don't think there is actually a limit.
How are you generating you command line?
Quote:
I suppose there is a way to split such long lines, but if i ever knew i forgot about it.
I'm not sure if there is under a normal AmigaOS shell but under sh (abc-shell) you can type a \ at the end of a line to continue onto a new one.
Do you actually need to profile every source?
Any way I would create something like that with a make file or perhaps arexx script rather than by hand. (ARExx tops out at 32768 characters for string though, so perhaps python)
My command line is 880 characters long, and the CLI accepts some 500 characters
The console can accept more than 800 characters. I booted inot Update6 to be sure I was using the public console and tested with along echo, I was still going at 900+ not sure what the limit is or where you get your 500 or so from.
Quote:
I was able to launch the command with a CLI script.
That's a much better way to do it anyway. I doubt if I could type 800 characters with out any typos
Quote:
it did not overwrite the gui.cno file that seems to have been produced yesterday (if at all with gcov gui.c the includes containing main(? source)
It is a binary file anyway
It's not supposed to. Did you run Gui4Cli first?
Did you get any errors reported by Gcov when you ran it after GUI4CLI ? Did you *quit* gui4cli before running?
@broadblues i think i respected everything ( i check again later) except eliminating the warning comparison is always true due to limited range of data type
for the second line here
port->mp_SigBit = AllocSignal(-1) ; if (port->mp_SigBit >= 0) /// warning
according to the .doc below a -1 output is possible though
What am i doing wrong?
exec.library/AllocSignal NAME AllocSignal -- allocate a signal bit
SYNOPSIS signalNum = AllocSignal(signalNum)
BYTE AllocSignal(BYTE);
FUNCTION Allocate a signal bit from the current tasks' pool. Either a particular bit, or the next free bit may be allocated. The signal associated with the bit will be properly initialized (cleared). At least 16 user signals are available per task. Signals should be deallocated before the task exits.
If the signal is already in use (or no free signals are available) a -1 is returned.
>Functions-adresse from binary : extract function names and offsets : thing like function foo() begin at offset 2000 and finish at offset 14000 (so is 12000 long) OK I have made a little C program "ObjDumpFuncs" that do that from an objdump file
It give this result
<ObjDumpFuncs: Microbe3D.asm > <============================> Function 0 01000074 16777332 _start 36 bytes Function 1 01000098 16777368 libOpen 136 bytes Function 2 01000120 16777504 libClose 100 bytes Function 3 01000184 16777604 libExpunge 272 bytes Function 4 01000294 16777876 libInit 228 bytes [...] Function 121 010051b4 16798132 LIB_Open 4 bytes Function 122 010051b8 16798136 LIB_Init 80 bytes [...] Function 402 0101a9e8 16886248 ShowPointNearMouse 472 bytes Function 403 0101abc0 16886720 OSLoadDT 596 bytes Function 404 0101ae14 16887316 OSLoadT 308 bytes Function 405 0101af48 16887624 ReadMTL 1640 bytes Function 406 0101b5b0 16889264 ReadOBJ1 804 bytes Function 407 0101b8d4 16890068 AutoSkinVN 1604 bytes [...] Function 430 01020000 16908288 SetMst 96 bytes Function 431 01020060 16908384 SetMt 84 bytes Function 432 010200b4 16908468 SetMs 96 bytes Function 433 01020114 16908564 SetMr 480 bytes Function 434 010202f4 16909044 MultMr 272 bytes Function 435 01020404 16909316 MultM 564 bytes Function 436 01020638 16909880 ClipTriangle 12332 bytes [...] Function 510 01033b70 16989040 strcpy 8 bytes Function 511 01033b78 16989048 strlen 8 bytes Function 512 01033b80 16989056 __NewlibCall 20 bytes <============================> <Functions: 513 > <Average size: 412 > <Max size: 12332 > <Min size: 4 >
>Functions-tree from a C source : what function call another function,etc... I obtain something like that
[...] Call 3052 101a3b4 16884660 Function ReadOBJ2 to ReadLine Branch 3053 101a3bc 16884668 Function ReadOBJ2 Call 3054 101a3cc 16884684 Function ReadOBJ2 to ReadName Branch 3055 101a3d8 16884696 Function ReadOBJ2 Branch 3056 101a3e0 16884704 Function ReadOBJ2 [...] Branch 3064 101a430 16884784 Function ReadOBJ2 Call 3065 101a438 16884792 Function ReadOBJ2 to NewListItem Call 3066 101a448 16884808 Function ReadOBJ2 to ReadFloats Call 3067 101a450 16884816 Function ReadOBJ2 to ReadLine [...] Not exactly a function-tree but all thta is needed to draw one
I will post the program to os4depot soon... if someone is interested
@broadblues However i still cannot generate the calllgraph i make use of predefined aliases that are presented below as if defined just before usage
G4C_18>alias GCCG4DL gcc guis:Dev/Gui4Cli_Dev/G4C_18/Gui.c -gstabs -fprofile-arcs -ftest-coverage -N -o g18:gui4clidl -lauto -lunix G4C_18>GCCG4DL G4C_18> delete Gui4Cli G4C_18> rename Gui4Clidl Gui4Cli G4C_18> gui4 d //gui4 lis the Gui4Cli launcher, which we copied in the G4C_18 drawer to be sure it launches this version // here we launch in debug mode, we open & close some Gui4Cli scripts then quit Gui4Cli
G4C_18>alias gcovG4 "gcov >g18:gui.graf timer.h errors.h textinhook.h command.h eval.h ...... gui.c " // very long command G4C_18>gcovG4 timer.gcno:cannot open graph file errors.gcno:cannot open graph file textinhook.gcno:cannot open graph file /// etc for all modules
gui.graf contains only the kind of info below for all source modules, no callgraph info
File 'guis:Dev/Gui4Cli_Dev/G4C_18/timer.h' Lines executed:0.00% of 60 guis:Dev/Gui4Cli_Dev/G4C_18/timer.h:creating 'timer.h.gcov'
File 'guis:Dev/Gui4Cli_Dev/G4C_18/errors.h' Lines executed:0.00% of 132 guis:Dev/Gui4Cli_Dev/G4C_18/errors.h:creating 'errors.h.gcov' etc
You don't need to specify all the include files just the source file.
But after a bit more reading I see that I've got my command output mixed up, gprof is the one that will produce a call graph in the sense that you mean (though only for functions called during your test run).
The .h files mentioned are actually source files (i inherited the situation as i am not the original author -this is D. Keletsekis. Don't know why he did choose to mention them that way but till now did not have reaons to change that.)
Why do i need callgraph gneration ? Generating a callgraph fom the source is obviously interesting to get a better understanding of the source and to debug it. You can build your own tools around it, more easily This is what i am doing: using Gui4cli-written tools to maintain & improve the Gui4Cli source. The first is part of my motivation to do the latter. I am more of a 'one-project' (amateuristic) C-programmer In general the avalable IDE's are too sophisticated and geared to "multiple projects" professional/experienced C-programmers.
Too bad gcov is not what i am looking for. (and gprof not working on SAM's :(( , although not ideal too, only generating the graph for used functions) Surely if the compiler/linker can identify the calls, generating a callgraph without running the program, is possible. I see a way in doing it (with Gui4cli) from the sources, but if feel there must be a better way using the compiler/linker built-in ntelligence, or the info in final binary or (and) in intermediate outputs. My knowledge of the compiling process is poor however. Having this kind of graph generation possibility, independent from a particular IDE, would be the great. I feel surprised there is no such tool known/readily available. It might help to attract new 'one-project' or 'first-project' programmers.
It might help convince some of them to improve - for example to try to add an arexx port - to their favorite open-source program (or add a a Gui4Cli port instead - which according to D.Keletsekis is more efficient and easy - i can confirm only it is easy)