hi, I'm building a valgrind tool, and as part of its functionality I need to get (and ultimately print out) local and global variable values based on their C types. However, I do not see a way to get detailed type information for locals and globals via the tool public interface.
The stack and global structs exported via VG_(di_get_global_blocks_from_dihandle) and VG_(di_get_stack_blocks_at_ip) give me back structs that include the variable name, the address, total size in bytes, and if it is an array or not, but this is not sufficient for my purposes. For example, if the variable is an array of 16 bytes I have no idea if it is an array of char, short, int, unsigned int, int *, etc., and if it is a struct or union I have no idea where the field types are, their names, nor their offsets and sizes from the base address, and if it is an array of structs or unions I have no idea if there is padding between elements or not, and enum and typedefs I'd just be out of luck. Even for non-array base types, I don't know if the value is signed or unsigned (ex. if 1 byte variable's value is 0xa1 is it -95 (char) or 161 (unsigned char)), and for Word sized values it could be a pointer or not, in which case I would want to display a pointer's value in hex, but if it is a long long I'd want to display it as a signed decimal. Since code in coregrind/m_debuginfo/ is parsing .debug to get the correct and detailed type information, offset, sizes, field names, etc., I'd like to get that info from coregrind for globals and locals through the public tool interface: it looks like the TyEnt struct has what I need. First, is there a tool interface to this detailed type information about variables that I am missing (like info in TyEnt structs) and if so, can someone please point me to it? If not (and I think this is the case), I would have to add something new to the public tool interface to get the information I need, adding or modifying code in coregrind/m_debuginfo/ to do it. I can build my own custom version of valgrind with the functionality I need, but this is obviously not ideal for keeping up with new version releases. Is there developer interest in expanding the valgrind public tool interface to export the kind of detailed type information that I need for my tool? If so, I'd be happy to discuss with someone the best way to design and implement it and help work on its implementation. Thanks, Tia ------------------------------- Tia Newhall Professor, Computer Science Dept. Swarthmore College www.cs.swarthmore.edu/~newhall pronouns: she/her
_______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
