|
From: Bryan M. <om...@br...> - 2006-08-28 17:26:16
|
Josef Weidendorfer wrote: > On Monday 28 August 2006 15:03, Bryan Meredith wrote: >> I agree that would be the best solution but how does one work out the >> compiler, given the IR (or is it buried in the debug info somewhere). > > If there is full debug information, you should be able to extract everything > you need (e.g. return type of a function). AFAIK, Valgrind currently does > parse symbol tables and line debug info, but not much more. > It would be cool to have a debug info parser for further info like type and > variable name available for tools (for DWARF format). > > Regarding push/pop vs. mov(sp): It can be that this is an architecture > optimization issue, and does change depending on command line options; > ie. not really depending on the compiler itself - but perhaps the defaults > for command line options have changed. Josef, I did wonder about whether it was default settings in the gcc spec file but didn't investigate it: it's not something that I can change (my own, no problem - everybody else's, hmmmm) so I have to be able to deal with it. I would expect the information to be in the debug somewhere but getting to it in a sensible way is the key. Doing the test on Ijk_Return is definitely _when_ to do it though. I currently try to spot it by the pattern of register writes but it simply isn't robust enough and optimised code kills it completely. I shall investigate making this information available for lookup as we already have function names so it could go with them I suppose (I have some other ideas relating to extending the line number storage that would benefit anything that needs per line information to be stored (mainly coverage type stuff) so I have already been looking in that area). Bryan |