Hi, sorry for reopening a very old thread, it took some time until I got around to write a script that parses the output of -fdump-ipa-cgraph and -fstack-usage. I'm using gcc 5.3 currently.
It's mostly what I need, I get all the information about the callgraph that I wanted to get (what's inlined, which functions was taken the address of, which functions contain indirect calls). With optimization, some of these indirect calls even disappear. Nice. But there are some things that turned out not so nice, which required workarounds. Any advice what to do about them? Put them into bugzilla, each as a separate ticket? Do you think that with nowadays, it would be better (simpler, more portable to new gcc versions) to write a plugin instead of parsing these dumps? I tried with a python plugin, but the call graph information I got in form of some gimple fragments wasn't very accessible. Did I miss the right API with which everything is easy, or do you have other hints on how to get the same information as in -fdump-ipa-cgraph and -fstack-usage? TMPDIR ====== This one is no big problem. But maybe someone can improve the documentation on this. When you build with -flto, some of the output doesn't go into the same folder as the executable. It goes into $TMPDIR instead. Except on Windows - there it goes into GetTempPath(). So my Makefile needs to handle Windows as a special case, and use a different environment variable there (TMP instead of TMPDIR). Wishes: - Document that the output of -fstack-usage goes into TMPDIR sometimes, and document the differece on Windows. - On Windows, use GetTempPath() only as a fallback when TMPDIR is not set - Output into the same directory as the executable Output of -fstack-usage is not accurate ======================================= This article mentions a "call cost": https://mcuoneclipse.com/2015/08/21/gnu-static-stack-usage-analysis/ I checked for myself, by looking at the change of the stackpointer with a debugger, and, yes, there seems to be a constant mismatch (2 bytes with avr-gcc-5.3) between change of stack pointer and output of -fstack-usage. In some rare cases there are more differences, which I didn't understand yet. Wishes: - Document that there is a call cost not included in -fstack-usage. Document what the call cost is, for each target architecture. - Preferred: Make output of -fstack-usage accurate Symbol identifiers in output of -fstack-usage are not unique ============================================================ In the output of -fstack-usage, there is the name of the source file, and the name of the symbol. Unfortunately, with -flto, this is not unique. Example: static inline functions declared in header files. Usually, the stack size will be the same in all translation units (and in my project I fortunately don't have this problem currently). But there is a chance that the stack size of a function changes depending on some macro that is different for different translation units. Fixing this would have the additional benefit that my script could be simpler because it would not need to know which object file name (as given in the output of -fdump-ipa-cgraph) corresponds to which source file name (as given in the output of -fstack-usage). Wishes: - Add stack-usage in output of -fdump-ipa-cgraph, so that you don't need to relate information from two input files at all. I guess this is not trivial. Or is it? Can you, in cgraph_node::dump, simply access the stack_usage "su" of struct function *get_fun (void); and in a sufficiently late pass the values will be valid? - In -fstack-usage, use the same unique identifiers as in -fdump-ipa-cgraph. The problem with that: This fix would probably break some other tools which parse the output of -fstack-usage. I'm considering to patch gcc myself. But because of the mentioned problem, there is no big chance that this will be accepted up-stream, is there? On first glance, this isn't hard - I found this in output_stack_usage: /* We don't want to print the full qualified name because it can be long, so we strip the scope prefix, but we may need to deal with the suffix created by the compiler. */ But on second glance, I noticed that this is a suffix with a dot - not the "order" of a cgraph_node with a slash. Is it possible to access this order in output_stack_usage? Regards, Sebastian On Thu, 14 Oct 2010 00:16:29 +0200 Richard Guenther <richard.guent...@gmail.com> wrote: > On Wed, Oct 13, 2010 at 11:43 PM, Sebastian > <sebastianspublicaddr...@googlemail.com> wrote: > > On Wed, Oct 13, 2010 H.J. Lu wrote: > >> GCC 4.6.0 has -fstack-usage. > > Thanks. That's probably the reason I didn't find it in current manuals. > > > > On Wed, Oct 13, 2010 Ian Lance Taylor wrote: > >> The mailing list gcc@gcc.gnu.org is for the development of gcc itself. > >> This question would be more appropriate for the mailing list > >> gcc-h...@gcc.gnu.org. Please take any followups to gcc-help. Thanks. > > Since this turns into a feature request, I hope it's ok to continue > > using this list. Of course, I will also enter it into bugzilla if nobody > > tells me not to (because it would be a duplicate of an existing request) > > > >> gcc can not dump a callgraph. Both GNU ld and gold can dump a > > Sure it can. In fact it does with -fdump-ipa-cgraph (ok, you need quite some > scripting to parse that into sth useful). > > Richard.
