> AFAIK, Julian recently added some functions to get at variable name for > a given stack address. You need it the other way around: get information > about number of parameter and types, and how to access them.
Yes, that information (parameter names and types) is definitely in the Dwarf3, and the new reader I did (readdwarf3.c) could probably be extended to collect it. Unfortunately readdwarf3.c is what you could call a complicated nightmare, so it might not be easy to make the extension. Certainly studying the Dwarf3 spec would be helpful. Another important question is to understand precisely what information you do need. I imagine it will be the locations of all parameters for the code addresses which are the entry points of functions. At the moment readdwarf3.c throws away information about variables that are in registers -- it only records info on variables that are in memory. The reason is that this was not required for the initial functionality (the exp-ptrcheck tool and to a lesser extent, Helgrind), and so that is definitely one thing that would need to be fixed. (Since on most platforms other than x86, at least some of the arguments are passed in registers.) J ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Valgrind-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-users
