pete@ohm.york.ac.uk (-Pete French.) (04/08/91)
Does anyone know of a program which will scan the symbol table of an a.out and produce a map showing which functions call which other functions ? It is possible to do this by hand using the output from nm - but I am sure someone must have written a tool to do this. Pointers to an ftp site anyone ? -bat. -- -Pete French. (the -bat. ) / "Two wrongs don't make a right, Adaptive Systems Engineering / - but three lefts do !"
matteo@ghost.unimi.it (Matteo Gelosa) (04/19/91)
pete@ohm.york.ac.uk (-Pete French.) writes: I'm working on an hp9000s855 risc machine and I worked a lot with all this stuff 'cause I'm writing an Objective-C debugger. >Does anyone know of a program which will scan the symbol table of an a.out >and produce a map showing which functions call which other functions ? It You mean a "function called list" for each function, do you? >is possible to do this by hand using the output from nm - but I am sure NM simly maps a function name with is start address, and prints it out, so how can you obtain a function calling tree? >someone must have written a tool to do this. >Pointers to an ftp site anyone ? Anyway, I don't know which machine you're working on so I can't tell you anything else! Write again on news I will give you help, if I will be able to do it. -- Matteo Gelosa E-Mail: matteo@ghost.unimi.it Universita' Statale di Milano - Italy
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/AA) (04/21/91)
As quoted from <1991Apr19.150727.17125@ghost.unimi.it> by matteo@ghost.unimi.it (Matteo Gelosa): +--------------- | pete@ohm.york.ac.uk (-Pete French.) writes: | >is possible to do this by hand using the output from nm - but I am sure | | NM simly maps a function name with is start address, and prints | it out, so how can you obtain a function calling tree? +--------------- If (and only if) you adhere to a one-function-per-source-file scheme, you can do this by treating "U" lines as refs and others as defs. If you have multiple functions per file, you lose: you can't localize it by function, only by file. ++Brandon -- Me: Brandon S. Allbery Ham: KB8JRR/AA on 2m, 220, 440, 1200 Internet: allbery@NCoast.ORG (QRT on HF until local problems fixed) America OnLine: KB8JRR // Delphi: ALLBERY AMPR: kb8jrr.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery KB8JRR @ WA8BXN.OH
jim@segue.segue.com (Jim Balter) (04/21/91)
In article <1991Apr19.150727.17125@ghost.unimi.it> matteo@ghost.unimi.it (Matteo Gelosa) writes: > NM simly maps a function name with is start address, and prints > it out, so how can you obtain a function calling tree? nm lists the symbol table, which may contain functions called and variables used, line numbers, struct and enum definitions, and much more, depending upon how the module was compiled and what has or hasn't been stripped from the symbol table. On SysV systems, at least, cflow is a shell script that gathers information from several kinds of files and runs it through dag (directed acyclic graph), which prints it out. It handles .o files (as well as .[csiyl]). It does not handle executables because generally the symbol table entries for enterns are merged and the call structure is lost.
mjr@hussar.dco.dec.com (Marcus J. Ranum) (04/22/91)
(this is *NOT* a product plug! - I hope it's interesting info.) There's a product out (from DEC, hence the disclaimer) called FUSE that has a graphical call-graph browser that's pretty nifty - it can analyse source (and I think object) and builds an X-window picture of the program's structure, with all manner of options to let you re-arrange how it presents the data. It's come in handy for me a couple of times, as a quick way to look at a mass of code and figure out sort of what it does. mjr.
bhoughto@pima.intel.com (Blair P. Houghton) (04/22/91)
In article <1991Apr21.190407.21323@decuac.dec.com> mjr@hussar.dco.dec.com (Marcus J. Ranum) writes: > (this is *NOT* a product plug! - I hope it's interesting info.) > There's a product out (from DEC, hence the disclaimer) called >FUSE that has a graphical call-graph browser that's pretty nifty - it >can analyse source (and I think object) and builds an X-window picture If you can get a copy of the 1989 (or was it '88?) ACM SIGPLAN/SIGADA conference proceedings, there are descriptions of about thirty such CASE systems in there, plus a few visual Unix environments. --Blair "Something about Ada makes noone actually want to see the code..."
jim@segue.segue.com (Jim Balter) (04/22/91)
In article <1991Apr20.171557.19792@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KB8JRR/AA) writes: >If (and only if) you adhere to a one-function-per-source-file scheme, you can >do this by treating "U" lines as refs and others as defs. If you have >multiple functions per file, you lose: you can't localize it by function, >only by file. Nope. Executables don't contain unresolved references ('"U" lines'). And in .o's, the unresolved references are bracketed by the function definitions and thus the call structure is determinable, and cflow does it. Number of functions per file is irrelevant.
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/AA) (04/23/91)
As quoted from <7205@segue.segue.com> by jim@segue.segue.com (Jim Balter): +--------------- | In article <1991Apr20.171557.19792@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KB8JRR/AA) writes: | >If (and only if) you adhere to a one-function-per-source-file scheme, you can | >do this by treating "U" lines as refs and others as defs. If you have | >multiple functions per file, you lose: you can't localize it by function, | >only by file. | | Nope. Executables don't contain unresolved references ('"U" lines'). +--------------- I took this as a given. +--------------- | And in .o's, the unresolved references are bracketed by the function | definitions and thus the call structure is determinable, and cflow does it. +--------------- ...as long as you don't play games with it. I've seen stuff that played tricks on .s files to move constant static strings into .text, which defeats this.... ++Brandon -- Me: Brandon S. Allbery Ham: KB8JRR/AA on 10m,2m,220,440,1.2 Internet: allbery@NCoast.ORG (restricted HF at present) Delphi: ALLBERY AMPR: kb8jrr.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery KB8JRR @ WA8BXN.OH